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INTRODUCTION 

The results of the refined conceptual design phase (Task 5) of the Simulation 
Computer System (SCS) Study are reported in this document. The SCS is the 
computational portion of the Payload Training Complex (PTC) providing simulation 
based training on payload operations of the Space Station Freedom (SSF). 

In Task 4 of the SCS Study, the range of architectures suitable for the SCS was 
explored Identified system architectures, along with their relative advantages and 
disadvantages for SCS, were presented in the Conceptual Design Report. Six 
integrated designs -- combining the most promising features from the architectural 
formulations -- were additionally identified in the report. The six integrated designs 
were evaluated further to distinguish the more viable designs to be refined as 
conceptual designs. The three designs that were selected represent oistmct 
approaches to achieving a capable and cost effective SCS configuration for the PTC. 

In this report, the results of Task 4 (input to this task) are briefly reviewed. Then, 
prior to describing individual conceptual designs, the PTC facility configuration and the 
SSF systems architecture that must be supported by the SCS are reviewed. Next, 
basic features of SCS implementation that have been incorporated into all selected 
SCS designs are considered. The details of the individual SCS designs are then 
presented before making a final comparison of the three designs. 
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1.0 Conceptual Design Findings 

1.1 Top Level Designs 

The range of SCS conceptual designs considered in Task 4 was the product of 
several system architectures combined with several trainer architectures. The top 
level designs numbered 1 - 6 are the different system architectures, and the letters A - 
D indicate the different trainer architectures. The system designs 1-6 represent the 
entire SCS architecture. The trainer designs A-D are alternative trainer subsets within 
these architectures. 


# 

NAME 

DESCRIPTION 

1 . 

Monolithic Host 

A single host for all SCS 
functions. 


Programmable Switch 

A programmable switch 
connects hosts to trainers. 


Local Host Network 

Local hosts connected via 
a network. 


Network Combined 

Trainer hosts combined 
plus a network. 

5. 

Shared Host Network 

Distributed network with 
shared hosts. 

6. 

Autonomous Trainers 

One host per trainer, no 
network. 

A. 

DMS Kit 

GFE DMS Kits are used. 

B. 

DMS Compatible 

DMS components or DMS 
like components. 

C. 

PCTC based 

DMS simulated in software 
on a host CPU. 

D. 

Distributed non-DMS 

No DMS Kits, processors 
on a network. 


Figure 1.1-1 SCS Top Level Conceptual Designs 

The following paragraphs discuss each of these top level designs. 

The Monolithic Host (System Design 1) means that all SCS functions would be 
performed on one single host computer. All trainers and facilities would be connected 
to the single host computer via point to point connection methods. This design is 
simple, using a single CPU type and single operating system, and provides straight 
forward centralized control. Many successful computer systems have been built in the 
past using this architecture. 

The Programmable Switch (System Design 2) provides multiple host computers 
that can be switched to support any trainer or any facility. This provides a high degree 
of fault tolerance and reconfigurability. Point to point connections are used. 
















TRW-SCS-89-T5 


Kefirssd Design 3 


The Distributed Network with Local Hosts (System Design 3) means that the 
trainers and facilities are connected via a network, but that each trainer and facility has 
one or more dedicated host computers directly connected to it. The network facilitates 
quick convenient communication between computers, aids in configuration 
management, and provides a means for centralized control. This design represents 
the current thinking in computer system design. 


The Distributed Network with Combined Subsystems (System Design 4) is a 
variant of Design 3. The basic idea is that some of the trainers may be able to use the 
same local host computer, thus reducing the number of computers required. 


The Distributed Network with Shared Hosts (System Design 5) means that none 
of the trainers have dedicated local hosts. The host computers are connected to a 
network and are only dedicated to a trainer for a particular training session. All data 
passed between the host and trainer for that session must now pass over the network. 
This design provides good fault tolerance and reconfigurability. The prob em is the 
potentially high traffic load on the network might make this design impractical. 


The Autonomous Trainers (System Design 6) means each trainer and I facility 
has a dedicated host directly connected, and the computers are not connected. This 
design is simple, and would have a lower cost than ones that include a network. Many 
successful systems have been built in the past using this design. 


The DMS Kit trainer design (Trainer Design A) uses DMS hardware to support 
core system simulations and payload flight software if available. This would promote 
easy interfacing of SCS payload simulations to the SSTF, since the SSTF will use 
DMS Kits. It also means that SCS hardware would not have to support all of the core 
and payload flight simulations. 


The DMS Compatible trainer design (Trainer Design B) uses partial DMS Kits 
or DMS Kits without a SIB to support the core simulations needed for training. The 
lack of a SIB would make it more difficult to interface SCS simulations. 


The PCTC Based trainer design (Trainer Design C) means that the core 
systems would be all simulated in software on a host computer. No DMS or 
compatible hardware would be used. This would cut hardware costs, but increase 
software costs. Transportability to the SSTF would be adversely affected. 

The Distributed Non-DMS trainer design (Trainer Design D) also means that 
core systems would be simulated in software, but that distributed processors would be 
used instead of a host computer. If COTS 80386 processors or personal Computers 
(PCs) could be used, some modified DMS software might be usable. 


1.2 Six Selected Designs 

By considering the six system level designs (1-6) in combination with the four 
trainer designs (A-D), 24 possible designs emerged. Using the evaluation criteria and 
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viable candidates for refinement in SCS Study Task 5. The six selected designs are 
identified in Figure 1.1-2 using the top level designators introduced in Figure 1.1-1. 


# 

Top Level Designation 

Name 

1 

< 

i 

CO 

Network Local Host - DMS 
Kit Trainers 

II 

3/5-A 

Network Local Host and 
Shared Host - DMS Kit 
Trainers 

III 

4-B 

Network Local Host with 
Combined Components 
DMS Compatible Trainers 

IV 

3-C/D 

Network Local Host - 
PCTC Based/Non-DMS 
Trainers 

V 

< 

04 

Programmable Switch - 
DMS Kit Trainers ' 

VI 

3-A/D 

Network Local Host - DMS 
Kit/Non-DMS Trainers 


Figure 1.1-2. Six Selected Designs 

The six SCS designs are described in the following paragraphs. 


I. SCS Integrated Conceptual Design 3-A . 

Integrates the Distributed Network Local Host architecture with the DMS Kit 
trainer design. The local hosts in each of the trainers perform all real-time 
simulation activities required to support payload training. 

The distributed network allows maximum flexibility for high speed 
communications between the SCS facilities or subsystems. Any facility can 
exchange data with any other facility using a single interface. The 
implementation of a single local trainer host for payload simulation executive 
functions is less complex from a system software viewpoint than implementing 
shared hosts at the SCS level. 

The use of the DMS Kits, including the SIB, is the SSE recommended approach 
to Space Station system development, integration, testing, and training. It is 
also the approach favored by the SSTF development effort at JSC. The use of 
the DMS Kit helps guarantee a high level of fidelity for payload training. Flight 
equivalent Space Station systems and payloads are easily integrated into the 
trainer with the DMS Kit. Also, Core system functional simulations, software 
developed for the SSTF, and SSE developed software would be directly 
transportable to the SCS. Likewise, PTC developed experiment models would 
be more easily transportable to the SSTF if developed in a DMS Kit 
environment. The SIB offers a great deal of functionality useful for simulations. 
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The SIB simplifies the implementation of some training requirements, like fault 
insertion. 

II. SCS Integrated Conceptual Design 3/5-A 

This design integrates a combination of the Distributed Network Local Hosts 
and Distributed Network Shared Hosts architecture with the DMS Kit trainer 
design. Individual shared hosts are allocated to perform real-time or non real- 
time functions, but not both. The real-time shared hosts support a different 
training scenario for each trainer. The local hosts support real-time training 
functions specific to a particular trainer. 

This design is somewhat similar to 3-A (# I) above and shares many of the 
advantages discussed. The use of shared hosts for non real-time functions 
offers additional flexibility, increased fault tolerance, and allows more powerful, 
more cost effective hosts to be utilized than a design with only dedicated hosts. 

III. SCS Integrated Conceptual Design 4-B 

Integrates the Distributed Network with Local Hosts and Combined Training 
Components architecture with the DMS Compatible trainer design. The 
Combined trainer is integrated with the Attached Payload trainer, and other 
trainers might be combined. 

This design utilizes a distributed network, like 3-A (# I) above. By combining 
trainers, a savings in equipment cost and possibly facility space can be 
obtained. The Part Task Trainers could also be combined such that a single 
host could support multiple Part Task Trainers. 

IV. SCS Integrated Conceptual De sign 3-C/D 

Integrates the Distributed Network Local Host architecture with the synthesis of 
the PCTC-based trainer and the Distributed Non-DMS trainer. This architecture 
does not have a DMS Kit or DMS components. Some trainer functions are 
implemented on the trainer host and some functions are implemented on 
dedicated processors. 

This design also utilizes a distributed network. The trainer design, with no DMS 
hardware components, offers flexibility of hardware configuration, and reduces 
risk resulting from uncertainties in the DMS Kit development schedule. In 
addition, COTS non-DMS hardware can be readily purchased from a vendor 
and is certain to be less expensive than DMS hardware. The use of non-DMS 
hardware does not necessarily preclude the use of DMS software. It is likely, 
however, that DMS software would require some degree of modification to run 
in a non-DMS hardware environment. 

The use of PCTC-based trainers would give the economic advantage of starting 
from an existing facility which could evolve into the finally required trainers. The 
advantage of using both the PCTC-based trainers and non-DMS trainers is that 
neither of these trainer designs contains DMS components, and the opportunity 
for synthesis between these two types of trainers thus seems good. The non- 
DMS design is a distributed, microcomputer based design that should 
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compliment and perhaps off set some of the disadvantages of the somewhat 
monolithic PCTC-based design. 

V. SCS Integrated Conceptu al Design 2-A 

Integrates the Programmable Switch with multiple host architecture with the 
DMS Kit trainer design. In this design, multiple trainers may be interfaced to the 
same host. The trainers may be switched and reconfigured quickly in the event 
of a host failure. 

The use of shared hosts makes maximum use of system resources. Any trainer 
can be quickly configured with any host, providing increased flexibility and fault 
tolerance. The use of dedicated point to point interfaces between the trainers 
and the hosts ensures that communication bandwidth problems are minimized. 

This design has a lot of promise. However, investigations conducted at the 
beginning of the Refined Design Task revealed that a switch capable o 
switching the required wideband high rate Direct Memory Access (DMA) 
channels currently does not exist. Existing switches can only handle 8 bit wide 
low rate channels. 


VI. SCS Integrated Conceptual Design 3-A /D 

Integrates the Distributed Network Local Host architecture with a combination of 
the DMS Kit trainer and the Distributed Non-DMS trainer. In this design, Non- 
DMS trainer elements are integrated with DMS trainer elements. Non-DMS 
trainer elements such as generic processors and peripheral devices are directly 
connected to the DMS LAN, instead of being directly connected to the SIB. In 
addition, elements of the Combined system approach are implemented in that 
the trainer host and SIB are shared across multiple trainers. 

This design is similar to 3-A (# I) above. The use of some non-DMS 
components in the trainer provides additional flexibility, and allows increased 
trainer functionality. Functional areas where non-DMS components could be 
desirable are instructor control and monitoring, audio/video systems, Core 
systems interface, and payload simulation control. These areas are envisioned 
to be implemented on the trainer host in other designs, but there could be 
advantages to implementing these functions in a processor directly attached to 
the payload LAN. 
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2.0 PTC/SCS Common Design Elements 


2.1 PTC Facilities Supported By SCS 

The basic SCS is comprised of a number of relatively independent computer 
based facilities combined to implement the breadth of SCS requirements outline in 
the SCS Concept Document. Figure 2.1-1 illustrates all of the PTC/SCS components 
required to accomplish the level and amount of payload training required tor 
successful SSF payload operations. Support for all of the facilities identified in Figure 
2.1-1 are included in each SCS design. The facilities consist of various trainer types 
capable of different levels of simulation fidelity and scope, and ancillary facilities 
providing training system support to the PTC. Many of the support facilities, as well as 
some of the trainer facilities, are implemented similarly across the three detailed 
designs. The major facilities comprising the SCS designs are discussed briefly in the 
following paragraphs. 

2.1.1 Consolidated Trainer 

The Consolidated Trainer is used for full fidelity, integrated training combining 
operations across the US Lab and attached payloads, Columbus Lab, and JEM Lab. 
The trainer represents the labs' payload systems, as well as all SSF core, 
communications, and space environment factors necessary for payload operations. In 
order to satisfy training requirements, the three labs are operated concurrently under a 
single integrated simulation session. Each of the constituent labs is a full scale, high 
fidelity laboratory module and experiment payload simulation system. The individual 
lab systems each support concurrent operation and representation of up to 24 payload 
experiments. 

The Columbus Lab and JEM Lab, which have currently undefined architectures 
that may not be comparable to the DMS, are interfaced to the DMS in the US Lab 
through network gateways. For present design purposes, the individual Columbus 
and JEM Labs are represented with a basic architecture of similar functionality to the 

US Lab. 

The Consolidated Trainer, and the other trainer types described below, provide 
for connection to flight equivalent payload instruments and to general purpose 
input/output devices used, in conjunction with software models, to simulate payloads. 

2.1.2 Combined Trainer/ Attached Payload Trainer 

The Combined Trainers are used for full fidelity single-lab training on the 
individual US, Columbus, and JEM Labs. Each Combined Trainer provides simulation 
of all lab payload and related SSF functions and supports a full complement of 
experiments. The three lab trainers operate independently. The attached payload 
trainer is used for full fidelity training on payloads attached externally. It operates 
independently, and it's design is exactly like the combined trainer. Thus, no separate 
drawings were made for it. 
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Figure 2.1-1 PTC/SCS Components 
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2.1.3 Part Task Trainer 

The Part Task Trainers are used, on a standalone basis, for fundamental 
payload training on a limited number of experiment payloads operating concurrently. 
Only the more important SSF and environment factors are represented in the 
simulations for typical training sessions. The Part Task Trainers are of two types. 1) a 
DMS Part Task Trainer, and 2) a Non-DMS Part Task Trainer. The DMS Part Task 
Trainer incorporates flight equivalent hardware and software interfaced to a host 
processor, while the Non-DMS Trainer consists of a workstation and instrument 
interfaces. The Non-DMS Part Task Trainer is intended to use payload models 
yielding SSF simulations at a level of fidelity below that of flight equivalent 
representations. 

2.1.4 Training Session Manager 

The Training Session Manager controls trainer configuration, setup, training 
management, and other non-real time PTC functions. The Training Session Manager 
resides on a central host connected to individual trainers over a common network. 

2.1.5 POIC Trainer 

The POIC Trainer provides payload-specific training for ground operations in 
the POIC. The trainer consists of several workstations connected to a central host. 

2.1.6 Development Facility 

The Development Facility provides the software development environment for 
PTC staff and principal investigators involved in developing, maintaining, and 
documenting the recurrent applications software for PTC operations. This software 
includes: simulation scenarios, payload models, other space station and environment 
models, environment data bases, stimulator programming, training evaluation and 
management software, IT&V software, computer based training (CBT) courseware, 
and programming and simulation utilities. 

2.1.7 Integration, Test and Verification (IT&V) Facility 

The Integration, Test and Verification Facility is used to test payload equipment and 
payload model operation within the PTC trainer environment. The facility architecture 
is modeled after the Combined Trainer because investigation showed that a 
successful IT&V facility needed more capability than a Part Task Trainer, but did not 
need to be a full up Consolidated Trainer. 

2.1.8 CBT Stations 

The CBT Stations are used for preliminary training and refresher training. 
These computer based trainers integrate audio, video, and computer graphics to 
provide a realistic introduction to lab and payload operations using abstract models 
and low fidelity physical representations of the SSF payload environment. CBT 
training is designed for self-paced, standalone sessions. 



2.1.9 Instructor Stations 

The Instructor Stations afford monitoring and control of simulation training 
sessions on one or more trainers. The console and associated software permit flexible 
supervision of training sessions with capabilities to: 1) duplicate the views a PP aa [ m 9 
on crew consoles and lab panels; 2) introduce device and data anomalies; 3) detect 
student actions; 4) communicate and route audio/video/digital information; and 5) track 
events/status of a simulation scenario. 

2.1.10 External PTC Interfaces 

The External PTC Interfaces enable communication links for data exchange 
with other centers including the POIC, Mission Planning System (MPS), and SSTF. 
The interfaces to POIC support the transfer of real time simulation data including table 
driven High Rate Link data, as well as programming files and management data. 

2.2 SSF Program - Architectural Concepts and Requirements 

The SSF program relies on several centers to provide mission support for 
system development, integration and test, and training. The architecture of the 
emerging SSF computing and communications systems has an immediate irnpact 
the PTC and other center requirements to simulate or incorporate these standardized 
systems To satisfy these requirements, the program is defining and developing the 
Data Management System (DMS) Kit. The DMS Kit includes flight equivalent 
processors, DMS software, consoles, mass storage devices, and I/O devices. The kit 
also includes the Simulation Interface Buffer (SIB) designed to provide control of the 
DMS components and connect them to a simulation host. 

The use of the DMS Kit eases the job of the training system developer by 
avoiding the duplication of the DMS architecture and functional capabilities which are 
fully implemented within the kit. Adopting the kit also avoids redevelopment in 
response to program modification of SSF flight hardware/software which should be 
reflected automatically in kit upgrades. The use of kits, however, may be economically 
limited to SCS implementations of those training systems required, by rigorous 
training objectives, to achieve flight-like fidelity. 

2.2.1 DMS Architecture 

The DMS architecture incorporates the Payload and Core systems and their 
bridge to the Communications and Tracking (C&T) system. The SSF specified 
implementation of the DMS invokes modular double and triple redundancy of the 
system components and their interconnections. For purposes of PTC simulation, the 
SCS must fully represent the payload segment of the DMS. One approach to 
achieving this representation is to employ SSF DMS Kits available for simulation 
applications. While the approach insures functional fidelity, aspects such as flight 
level redundancy may not be replicated in the kits. 
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2.2.1 .1 DMS Kits 

The DMS Kit is comprised of equivalents of the DMS components and software 
used on the Space Station with the companion SIB provided as the link to i the user s 
simulation hosts. The SIB is not part of the SSF hardware complement The DMS KU 
includes direct connections from the SIB to all DMS components, enabling the SIB to 
control and, in some cases, emulate the DMS components. Additional information on 
the DMS Kit is given below. For more detailed information see the 'Jest issue of the 
"Prime Item Development Specification, Data Management System Kit , # SP-M 0 
March 16, 1989. 

The DMS components are a set of processors, peripherals, and terminals that 
are fliqht equivalent hardware and software developed for the SSF. The u 
components include operations and data management software and the Payload LAN. 
The principal DMS component types are listed below: 


-Standard Data Processor (SDP) 

-Mass Storage Unit (MSU) 

-Time Generation Unit (TGU) 
-Multiplexer/Demultiplexer (MDM) 

-Multipurpose Application Consoles (MPACs) 

-Bus Interface Adapter/Network Interface Unit (BNIU) 
-Core LAN (FDDI based) 

-Payload LAN (FDDI based) 

-Local Bus (MIL-STD-1 553B or IEEE 802.4 based) 
-Network Bridge 
-Ring Concentrator 
-Star Coupler 


The DMS components are designed with a great deal of commonality. This 
commonality extends to the enclosures, backplan es ( p r ocesso rs , pe ri ph era I s , 
interfaces, and operating system software. The SDP, MSU, f |xe ^ MPAC (F-MPAC), 
and MDM are all based on a backplane architecture such as Multibus II. These 
components derive their unique functionality from the specific configuration of boards 
and software installed on the backplane. 


Fiqure 2 2-1 illustrates the important input/output features of the basic DMS 
component architecture. These channels represent the primary means of interfacing 
DMS components and other computing equipment to integrate a complement of 
trainers within the SCS. 


The Core and Payload LAN are the network backbone of the DMS. These 
LANs are currently based on the Fiber Distributed Data Interface (FDDI) ^twork (ANSI 
X3T9 5). This is a dual token ring, fiber optic LAN with a nominal bandwidth of 100 
Mbps The Payload LAN is the same type of LAN as the Core and is connected to the 
core LAN via a network bridge. The DMS components residing on the Payload LAN 
are attached to the FDDI through ring concentrators. Connection to the Columbus 
module and JEM module networks is accomplished through network gateways. 


FDDI I 1 | 

NETWORK EDP-4 
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Figure 2.2-1 Basic DMS Component I/O Architecture 
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A Network Interface Unit (NIU) is used to interface the DMS components 
supporting the Payload LAN. The NIU card set provides all the services required by 
the Network Operating System (NOS). The NOS facilitates interprocess 
communication by providing a standard means for data exchange between 
applications. 

The Embedded Data Processor (EDP) is included in all DMS devices that 
require processing capability. This includes the SDP, MSU, MPAC, and versions of 
the MDM. In operation, the EDPs support DMS standard services as well as the 
software unique to their local applications. 

The Bus Interface Adapter (BIA) provides the interface of EDP/SDP components 
to the Local Bus. The Local Bus is a network based on MIL-STD-1553B or IEEE 802.4. 
A Small Computer System Interface (SCSI) interface provides connections to the 
mass storage devices required by the MSU and the MPAC. The analog and digital I/O 
adapters of the MDM connect to the Local Bus. In the SSF DMS configuration, the 
Timing Generation System (TGS) connects the TGU to each DMS component over a 
separate Timing Distribution Bus (TDB). The TGU is connected to an SDP attached to 
the Core LAN. In conjunction with the currently specified SIB, however, the TGU is 
attached only to the SIB and the Local Bus through a star coupler. 

The user interface within the DMS is the MPAC. This console provides a 
windows environment supporting concurrent access to systems status data, video 
data, user communications, C&W messages, et cetera. When appropriate, the MPAC 
may serve as a repeater for payload C&D panels affording direct monitoring and 
control of multiple payloads from a single station. The console also provides 
capabilities to perform payload related control actions and to store data. The fixed 
MPAC (F-MPAC) is attached to the Payload LAN, while the portable MPAC (P-MPAC) 
connects to the DMS Local Bus. 

2.2.1.2 SIB 

The SIB is the mechanism for connecting external computer equipment to the 
DMS. The SIB is not part of the Space Station hardware, but is being developed by 
the Software Support Environment (SSE) contractor to facilitate the connection of host 
computer systems to the DMS. In the latest baseline, the SIB provides a dedicated 
high speed link to a host computer, and allows the host to interface with the payload 
FDDI LAN and other busses which interconnect DMS components. The SIB can 
directly control DMS components in order to govern and recreate the course of 
simulated events. It may also substitute for the function of DMS components such as 
the TDB. Like the DMS components, the SIB design is modular and based on a 
common backplane. 

The SIB supports connections to the: 1) FDDI network through a ring 
concentrator; 2) 802.4 Local Bus through a star coupler; 3) 1553 Local Bus; and 4) 
Time Distribution Bus. The SIB provides a SCSI interface to SDPs, MSUs, MDMs, and 
F-MPACs. While the SIB can access SDPs and MDMs through the FDDI connection, 
the SCSI interface through embedded SDDUs affords the SIB greater control. With 
this scheme, the SIB can start, stop, insert breakpoints, and otherwise control low level 
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functions of an SDP or MDM based on internal events. It also is capable of logging 
and replaying bus traffic sufficient to recreate the DMS aspects of a simulation session. 


2.2.2 Space Station Freedom Program Tools and Facilities 

The SSF program has provided certain tools and facilities for use in system 
development. These software tools are designed to ease sy ^erri developmen , 
integration, and testing. The Software Support Environment (SSE) Prov'des the 
analysis, design, and production tools to be used in common across the bbr- 
development efforts. Systems integration of the SCS will be expected to rely on the 
accepted SSE set of development tools. 


3.0 SCS Designs 


3.1 Selection of Three Designs 

The three SCS designs detailed in this report illustrate implementations offering 
varying degrees of resource sharing and utilization of the SSF DMS architecture. The 
designs attempt to satisfy the SCS requirements specified in the SCS Concept 
Document however omission of capabilities in the designs does not waive these 
requirements. Each design offers a somewhat different profile of performance, cost, 
and schedule. 

The selection of the designs for refinement was based on several 
considerations including the following: 

-Networks are preferable to point to point connections due to their inherent 
flexibility. 

- Incorporation of DMS kits minimizes the difficulties of managing different DMS 
configurations on the Space Station. In the PTC, it reduces the risk of software 
development, and simplifies software portability. 

-Use of modular hardware and software, and the distribution of processing 
capabilities, where feasible, increases the reconfigurability and expandability of the 
system. 

-Real time functions, processing, and communications should always be 
segregated from non-real time functions. 

The three selected designs map to the six recommended in the Task 4 effort, but 
are not simply three of the six recommended. Due to the uncertainties in DMS Kit and 
SIB design uncovered in the first part of the Task 5 effort, it became clear that the three 
Task 5 designs selected to be refined needed to be broader than or, 9 ,r I al| y 
envisioned. Discussions with all members of the SCS team, including NASA, yielded 
the fact that the Task 5 investigation must address three possibilities: 
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1) The DMS Kits and the SIB will be available when needed by SCS, and the 
SIB will only connect to a host computer through a point to point parallel 
connection (like a Digital Equipment Corporation VAXBI 32 bit wide parallel 
interface). 

2) The DMS Kits and the SIB will be available when needed by SCS, and the 
SIB will connect to a network through a high speed fiber optic connection. 

3) The DMS Kits and the SIB will not be available when needed by SCS, or if 
available, are designed to meet flight system development and not training 
functions. 

The designs selected to help address the above three possibilities and be 
refined were given names in order to avoid any indication at the outset of Task 5 that 
one design was favored over the others. The three selected are: 

LOCAL HOST - This is the Network Local with DMS Kit Trainers (top level 
designation 3-A) and Task 4 recommended Design I (3-A : Network Local Host - 
DMS Kit). It addresses possibility number 1 above. 

SHARED HOST - This is the Shared Host with DMS Kit Trainers (top level 
designation 5-A) and a variant of Task 4 recommended Design II (3/5-A : 
Network Local Host/Shared Host - DMS Kit). It addresses possibility number 2 
above. 

DMS EQUIVALENT - This is the Network Local Hosts with Non-DMS Trainers 
(top level designation 3-D) and a variant of Task 4 recommended Design IV (3- 
C/D : Network Local Host - PCTC Based/Non-DMS). It addresses possibility 
number 3 above. The PCTC Based option, although completely viable, was not 
included for further study because there is little need to explore through a "what 
if" design study a facility and design that currently exists. Also, this approach 
represents design methods reflecting state-of-the-art design from when the 
PCTC was developed, not current system design thinking. 

A top level view of each selected SCS design is shown in Figure 3.1-1 through 
Figure 3.1-3. 

The next section describes the SCS design features that are shared by all three 
designs. Variation in the implementation of these features is noted when appropriate. 
Subsequently, the unique configurations and distinguishing features of each SCS 
design are addressed in separate sections. 

3.2 Common Design Features 

In earlier phases of the study, a broad spectrum of architectural concepts was 
explored for possible application to the SCS. Several design guidelines for SCS 
emerged from these examinations. Following these guidelines, the selected SCS 
designs exploit variations along key architectural dimensions while other aspects of 
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Figure 3.1-2 SCS Shared Host Design 
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the architecture remain constant. The common features shared across designs occur 
in the following areas: 

Payload Representation 
Core Systems Representation 
Crew Interface Representation 
Audio/Video Systems Representation 
Facility Architectures 
Simulation Control and Monitoring 

3.2.1 Payload Representation 

The payload representations consist of either the flight equivalent payload 
hardware and software or a software payload model and associated control and 
display hardware. The flight equivalent article includes the DMS compatible 
instrument, a flight equivalent Control and Display panel, and associated flight 
equivalent software The software payload models consist of software that runs, under 
the simulation executive, either on the trainer's simulation host or in a DMS 
component processor. 

Because flight equivalent payloads are expected to be available for payload 
training-only 10 percent of the time, the majority of payload training will rely on the 
execution of software payload models. Further, the software payload models must 
achieve sufficient fidelity and robustness to drive simulation training sessions within 
both the PTC and, ultimately, the SSTF. Consequently, each SCS design must 
provide substantial computing capability within the real time simulation environment. 

Flight equivalent payloads need to be appropriately stimulated to replicate the 
effects experienced in orbit. This stimulation includes direct sensor activation, effector 
feedback, and the ambient effects on the experiment of the space station’s 
environment. The payload stimulator is an intelligent controller receiving data from the 
Core and environment models. The stimulator connects to a host I/O port and to the 
flight equivalent hardware directly and/or through the Local Bus. Within each trainer, 
the payload stimulators may also be responsible for controlling or emulating the 
necessary GSE services to sustain the payload. 

The payload C&D panels associated with individual experiments are high 
fidelity functional equivalents of flight hardware positioned realistically in a trainer's lab 
mockup. Two panel types exist: 1) a generic reconfigurable terminal system i.e. a 
"virtual panel"; and 2) a hardware replication of the flight payload panel. In addition to 
the panels, activation of other experiment devices and associated lab support 
equipment furnished within the physical lab mockup will be implemented by SCS as 
required by training objectives. 

3.2.2 Core Systems Representation 

A representation of the Space Station Core systems is required to support any 
payload simulation using flight equivalent or software model implementations, e.g. 
power systems or GN&C must be simulated. For purposes of SCS conceptual design, 
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Core systems are treated as representing all space station systems that affect pay oad 
operations or performance, other than those encompassed by the DMS Payload LAN 
which is represented by hardware in all DMS designs. Core systems representations 
that interface with payload simulation include: Communications and Tracking (C&T), 
Guidance, Navigation, and Control (GN&C); Electrical Power; Thermal Control; Fluid 
Management System (FMS); and various lab support systems such as the Process 
Materials Management System (PMMS). 

Environment models and data bases to represent the dynamic space and space 
station environments are also included in the Core systems category for convenience. 
Environment models may represent several ephemeral and other factors including 
gravity, celestial positioning, station dynamics, solar effects, mass properties, ambien 
conditions, and atmospherics. The Global Positioning System (GPS) mode 
necessary to drive the TGS within the DMS may also be considered an environmental 
model In this case, however, an actual electronic signal must be generated to 
stimulate the TGU. This capability is explained as part of the Payload Stimulator for 
the Local Host design described in Section 3.3. 

The scope and fidelity with which Core system events and data need to be 
represented vary from one payload to another. For example, some payloads will 
require precise positioning data from the GN&C system, while these data will be 
entirely irrelevant to other payloads. It is assumed that software models of the Core 
systems, station environment, and flight equivalent DMS core software will be 
available from other SSF development programs. 

Although the Communications and Tracking (C&T) system is included in this 
broad grouping, its relationship to telemetry presents unique requirements that are 
often handled separately in the SCS designs. The associated C&T model provides 
formatted uplink/downlink communications containing SSF data from the: 1) Payload 
LAN; 2) Core systems LAN; 3) payload High Rate Link; and 4) other audio/video 
sources. Payload LAN data and High Rate Link data may be obtained from both 
actual flight equivalent payloads and payload simulation models. The C&T model 
requires dedicated hardware to generate the telemetry data stream necessary to feed 
the POIC Trainers and the POIC. 

All SCS designs incorporate a C&T telemetry system processor/controller to 
satisfy the C&T requirement. The processor/controller is shared among the design’s 
lab trainers through a patch panel which routes one trainer’s C&T-bound output to the 
processor/controller. In the DMS Equivalent design, C&T is implemented utilizing a 
distributed microcomputer. The output of the C&T is an SSF compatible telemetry data 
stream that can can be received by the POIC. The simulator inputs to the C&T include 
HRL, payload LAN, Core LAN, and host I/O feeds of science and command/status 
data.’ The C&T implementation also supports bi-directional SSF voice communication 
streams. 

3.2.3 Crew Interface Representation 

The accurate functional and, in some cases physical, representation of the 
various features of a payload that a crew member may interact with is, of course, 
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critical to simulator training. The two primary interfaces for monitoring and control are 
the rack mounted experiment's attached C&D panel and the lab's multipurpose 
application console (MPAC). Additional payload features such as mechanical controls 
are considered part of the lab-payload physical mockup and involve minimal 
interfacing to the SCS. 

3.2.3.1 C&D Panels 

The C&D panel consists of switches and indicators that provide payload control 
and display of information. When flight equivalent payloads are used, the associated 
C&D panel is integral to the hardware. Alternatively, when payloads are simulated 
with software models, the associated C&D panel may appear in two versions. One is a 
close replication of the actual panel hardware used on the flight payload. This is a 
custom designed piece of hardware dedicated to a particular payload experiment. 

The other option uses a "virtual C&D panel" incorporating a high resolution 
touch sensitive graphic display and appropriate I/O interfaces to achieve a functionally 
accurate representation of the actual flight panel. The virtual panel, as depicted in 
Figure 3.2-1, can quickly be reconfigured to represent the control and display 
elements making up any flight payload experiment panel, including ones from different 
increments. 

3.2.3.2 Crew Console - Multipurpose Application Consoles (MPACs) 

The basic MPAC currently planned for the SSF is implemented within the DMS 
based SCS trainer designs using the DMS Kit supplied flight equivalent MPACs 
attached to the Payload LAN. Representation of the portable MPAC (P-MPAC) will be 
provided as needed and will implement a DMS Local Bus connection. In non-DMS 
trainer designs, the MPACs are implemented using appropriately outfitted graphics 
workstations and graphics terminals connected to an SCS Trainer LAN. In all SCS 
designs, the Combined Trainers have been configured with two crew consoles; the 
Consolidated Trainer with two consoles in the US Lab and one each in the JEM Lab 
and Columbus Lab; and one console in each Part Task Trainer. 

3.2.4 Audio/Video Systems Representation 

The Audio and Video Systems' capabilities accommodate onboard space 
station and lab internal communications and CCTV, audio communications with the 
ground, payload generated video, and computer generated imagery to simulate visual 
scenes and events associated with flight payload operations (such as viewing a star 
field). Speech synthesis and recognition permit automated simulation of verbal 
communications during a training session. A basic audio/video system is diagrammed 
in Figure 3.2-2. Internal PTC facility intercom and CCTV for instructor communications 
and training monitoring are not specified as part of the SCS in this document. 

3.2.5 Common Facility Architectures 

Many of the support facilities are common across the SCS designs. These 
facilities include the Development Facility, External PTC Interfaces, POIC Trainers, 



TRW-SCS-89-T5 


Refined 1 Design 2 2 



Figure 3.2-1 Virtual Control & Display Panel Design 
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Figure 3.2-2 Audio & Video System Design 
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IT&V Facility, CBT Stations, Training Session Manager, and central Instructor Stations. 
A top level view of the facilities architecture is presented in Figure 3.2-3. 

3.2.5.1 Development Facility 

Because it is expected that 90 percent of the payload experiments installed in a 
trainer will be software simulation models, rather than flight equivalent payload 
hardware and software, a substantial SCS Development Facility is required. The 
facility has been designed to support on the order of 100 concurrent users performing 
a mix of software development tasks without impinging on the SCS LAN. 

The facility connects 40 workstations and diskless workstations to dual file 
servers via a local LAN. The diskless workstations are economical and will support 
the development function. The file servers provide common access to central code 
libraries, data dictionaries, batch job facilities, and configuration management tools. 
The workstations support the bulk of program design, code generation, compilation, 
and local configuration management. The dual file servers also provide the 
computational resource for 60 ASCII and graphics terminals (diskless workstations) 
attached to the local LAN through a terminal server. These terminals support source 
code editing, documentation authoring, and testing tasks, as well as batch job 
submission. The file servers connect to the SCS LAN to permit developed software to 
be downloaded to the SCS trainers and other facilities. 

Figure 3.2-3 also depicts a documentation system and a portable test unit 
residing in the Development Facility. The documentation system is based on COTS 
publishing software running on a dedicated host. The portable test unit adapts the 
workstation to support payload interfacing/emulation for debugging payload models 
prior to IT&V testing. The test unit, shared by several developers, facilitates 
independent model development and should shorten the overall development cycle. 

3.2. 5. 2 External Interfaces 

The PTC/SCS will provide a real time interface to the POIC. This interface 
allows uplink/downlink data to be exchanged between the SCS and the POIC. Other 
facility interfaces will allow file transfers between the MPS, SSTF, and the Pis. The 
interfaces are implemented as gateways to appropriate wide area networks (WANs). 
The gateway host resides on the SCS LAN. Interfaces that must support full telemetry 
data streams are implemented with the host and an attached I/O processor. 

3.2.5.3 POIC Trainers 

The Payload Operations Integration Center (POIC) Trainers are provided for 
training POIC personnel in payload operations independently or in synchronization 
with lab trainers. Each POIC Trainer consist of a host processor and two workstations 
sharing the SCS LAN. The workstations serve as ground personnel stations. 
Instructor stations are located on the SCS LAN and are shared with other SCS 
trainers. The POIC trainer is connected to the SCS LAN and to an interface for the 
telemetry data stream. When this data stream is of moderate bandwidth, it may contain 
simulated or actual DMS Payload LAN data and High Rate Link data. Full capacity 
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dynamic downlink data streams, however, require a telemetry system 
processor/controller which is linked to a comparable C&T processor fed by one of the 
SCS lab trainers. Audio and video signals are represented realistically in the POIC 
trainers with appropriate video monitoring capabilities. 

3. 2.5.4 IT&V Facility 

The IT&V Facility is used to integrate and validate, within the SCS lab trainer 
environment, the: 1) payload simulation models; 2) other SSF and environment 
models; 3) flight equivalent hardware and software units; and 4) physical and virtual 
payload C&D panels. These elements are operationally tested within the DMS, Core, 
C&T, and control aspects of the simulator configuration. LAN and bus monitoring 
capabilities and processor breakpoint capabilities are implemented within the facility 
using the SIB or comparable utilities. In all SCS designs, the architecture of the IT&V 
Facility is essentially identical to the Combined Trainer architecture. The facility 
connection to the SCS LAN permits software modules to be downloaded from the 
Development Facility. 

3. 2. 5. 5 CBT Stations and Facility 

The CBT Stations consist of interactive graphic, video, and audio capabilities 
implemented on a workstation running customized courseware. The facility consists of 
several CBT Stations connected to a file server over a local LAN. The CBT file server 
is connected to the SCS LAN for downloading software and courseware from the 
Development Facility. Provision for local removable media such as optical, video, or 
magnetic disk is included. 

3.2.6 Simulation Control and Monitoring 

3.2.6. 1 Training Session Manager (TSM) 

The Training Session Manager (TSM) operates as a high level system 
executive residing on a single host attached to the SCS LAN. The TSM 
communicates directly with the simulation executive programs residing on the 
dedicated, shared, or distributed trainer hosts. The TSM controls access to the trainers 
on the SCS LAN and mediates all file transfers and message traffic. While most 
functions like setup and initialization precede simulation session running, near real 
time responsibilities do exist including supervision of Instructor Station requests. In all 
SCS designs, the Training Session Manager and its host are responsible for external 
interface communications with other facilities. 

For purposes of SCS conceptual design, a common approach has been 
adopted for aspects of the simulation executive and its synchronization of real time 
simulation processing. The basic scheme is assumed to broadcast simulated space 
station systems/environment status information at a periodic rate to all DMS and 
payload representations simultaneously. This Core data and Core mediated 
environment data, output from the corresponding simulation models, are posted at 
least once every second for use by payload models and/or actual devices 
communicating with the DMS Payload LAN. Control and payload generated data 
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remain asynchronous and continue to be transmitted as they arise. The scheme 
accommodates the range of SCS designs considered here by ensuring an or ery 
means of communicating rapidly among the various simulation models and devices 
even when their host processors are distributed across the SCS. 

3.2.6.2 Instructor Stations 

The Instructor Stations are attached to the SCS LAN and communicate with the 
individual trainers through the simulation executives residing on the trainer hosts. The 
TSM monitors this communication to prevent inappropriate commands from disrupting 
real time simulation processing during a training session. Direct access to the 
simulation executives is granted to monitor status information and replicate the views 
appearing on the students' crew consoles and C&D panels. The stations are 
implemented as workstations with interfaces to the Audio and Video Systems and are 
represented in Figure 3.2-4. 

3.2.7 Common Design Options 

An additional feature shared by all SCS designs is the wide range of interface 
options supported. Within the SCS architectural context, capabilities are provided in 
each of the following areas: 

Payload Representation 
Core Systems 
C&D Panel 
Audio/Video System 

3.2.7.1 Payload Representation Options 

An attempt has been made across all SCS designs and their trainer types to 
integrate payload representations, of whatever kind, within the trainers in a consistent 
manner. Overall, the approach has been to accommodate as many interface schemes 
as are useful within a trainer design. Minimally, this has meant that each trainer 
provides a flight payload instrument interface, a C&D panel interface, and a pay oad 
model to DMS representation interface. DMS based trainers also provide a flight 
equivalent C&D panel interface and alternative methods of interfacing the flight 
equivalent payload instrument to DMS Kit components. The full mission trainers 
(Consolidated Trainer and Combined Trainers) in all three SCS designs could support 
all means of payload representation and C&D panel interfacing simultaneously. 

Figure 3.2-5 illustrates the variety of payload representation options that will be 
discussed in detail in the following sections. 

3. 2.7. 1.1 Flight Equivalent Payload 

The flight equivalent payload consists of rack mounted or attached instrument 
chassis, an integral C&D panel, application software, and perhaps peripheral 
equipment. The payload may also utilize associated lab facility hardware provided to 
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Figure 3.2-4 Instructor Station 
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support related experiments. The alternatives for integrating flight equivalent payload 
instruments into a trainer involve the following interfaces: 

1. A flight equivalent payload, with its own NIU equivalent, connects directly 
to the Payload LAN. 

2. A flight equivalent payload connects to an SDP through standard 
onboard I/O, or through an additional I/O adapter/controller attached to 
the processor bus. 

3. A flight equivalent payload connects to an MDM. 

4. A flight equivalent payload connects to a MDM or SDP as in (2) or (3), 
and has software executing on the component's EDP. (Not illustrated) 

5. A flight equivalent payload, with its own standard I/O port, connects 
directly to a trainer's host computer. (Not illustrated) 

6. A flight equivalent payload (with its own BIU) connects directly to the 
Local Bus. 

These options are shown in Figure 3.2-6. The numbers in the upper right hand 
corner of each payload connection option correspond to the six listed above. 

Where flight equivalent payloads are employed, a payload stimulator is 
required to provide sensor excitation and other ambient effects to the payload that 
would normally occur in flight. The stimulator is driven by Core and environment 
simulation models and data bases which represent the Space Station environment, 
and crew actions. A payload stimulator may furnish comprehensive real time 
stimulation to achieve the highest level of payload operation fidelity, or the stimulation 
may represent with some approximation only the more critical stimuli affecting payload 
operation and performance. 

For control purposes, the payload stimulator can be integrated into a trainer 
using three different interfaces: 

1 . A payload stimulator connects to a trainer host directly using standard I/O 
port (RS232 or SCSI). 

2. A payload stimulator attaches to the DMS Local Bus (and connects with 
the trainer host through the SIB). 

3. A payload stimulator attaches directly to the trainer’s network (Payload 
LAN or Trainer LAN), the latter being the case in a design without a DMS 
Kit. 

The last connection requires that the stimulator incorporate a processor based 
controller and network interface. A dedicated processor could also allow the 
stimulator to operate autonomously, interfacing directly with the Core and environment 


Refined Design 3 1 
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models over the Payload or Trainer LAN. 

3.2.7. 1.2 Software Simulated Payload 

There are two aspects of integrating a software simulated payload into a trainer. 
First, the payload model must be hosted on a trainer host and interfaced with the 
trainer’s DMS representation. Second, the associated hardware, providing a 
representation of the payload s control and display elements (e.g., C&D panel), must 
be interfaced within the trainer. 

Alternative model interfaces can be implemented in the following ways: 

1 . A payload model executing in a local or shared host is interfaced to DMS 
or DMS compatible components through a SIB or other controlling 
device. 

2. A payload model executing on an SDP, an EDP in another DMS 
component, a Dedicated Experiment Processor (DEP) or an SDP 
compatible processor, is connected to the Payload LAN, or to the 
Local Bus, or to both. 

3. A payload model executing on a dedicated, distributed host is connected 
to the Payload LAN. 

The options associated with a software simulated payload alternatives 
and DMS Kit based trainer are shown in Figure 3.2-7. The numbers in the upper right 
hand corner of each payload simulation option correspond to the list above. 

3. 2.7.2 Core System Options 

The Core system can be represented with a suite of software models that 
interface with the DMS Kit or with the DMS Equivalent distributed host system. Other 
designs could incorporate flight equivalent components of the Core system as part of 
their DMS Kit trainer implementations. Such implementations could include the Core 
LAN and Core software available under the SSF program. Core software would be 
run on an existing SDP, or an additional SDP, in the DMS based trainers. This 
approach would make maximum use of flight equivalent software and available 
environmental models. These flight equivalent models will be built by other centers, 
and modifying and using these existing models as needed to support payload training 
could represent a significant cost savings in the building of the SCS. Using these 
models would also mean a more direct tracking of Core systems implemented within 
the SSFP by SCS through out the life cycle of the SCS. Any changes could be 
incorporated by transferring the new flight equivalent software rather than changing 
SCS software core models. The SCS Study has demonstrated that flight software and 
engineering models can be used, as well as training models. Use of SSFP Core 
system software would also help ensure easy integration of flight equivalent payload 
simulations. However, this approach, while reducing the amount of simulation 
software needed to represent Core functions, creates additional SCS requirements. 
The incorporation of Core components creates a more complex trainer configuration to 
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Figure 3.2-7 Payload Simulation Options 
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maintain. It also dictates more comprehensive high fidelity environment models and 
space station models to drive the actual Core systems realistically. The options for 
interfacing payloads, however, should not be affected by this choice in DMS 
representations, except that more comprehensive payload models may be required to 
accept actual Core systems data. 

Depending on the particular SCS Study design, Core systems models execute 
in a central Trainer Host or in an SDP or dedicated processor in the DMS Kits. Flight 
equivalent DMS core software running in a DMS SDP may also be utilized. The 
choices of where to run core software models, and some of the other options for 
utilization of DMS Kits discussed are illustrated in Figure 3.2-8. In this figure, dashed 
lines or shaded ares represent the various options. 

3. 2.7. 3 C&D Panel Options 

C&D panels associated with the payload software model can be connected to a 
host I/O port or to the DMS Local Bus. C&D panels can also connect to CMDMs which 
reduces the amount of intelligence needed on the C&D panels themselves. 

The C&D panel associated with a software payload model must be driven such 
that signals can get to the simulations from the panel, and indications can be sent from 
the simulation to the panel. Figure 3.2-9 illustrates C&D panel connection options. 
Panels can be processor based and support the following means of interface: 

1 . A C&D panel connects to a trainer host directly using standard I/O port 
(RS232 or SCSI). (Not illustrated) 

2. A C&D panel attaches to the DMS Local Bus. 

3. A C&D panel attaches directly to the Payload/Trainer LAN. 

4. A C&D panel connects to an SDP via an I/O adapter attached to the 

processor bus. 

5. A C&D panel connects to a MDM. 

6. A C&D panel is part of a flight equivalent payload. 

Both physical and virtual versions of the detached C&D panels are designed 
with sufficient onboard I/O processing to support direct connections to a host I/O port 
(SCSI or RS-232) or to the DMS Local Bus. Both panel types and all connection 
schemes can be supported simultaneously by the SCS designs. The arrangement 
allows the appropriate C&D panel to be connected directly to whatever processor is 
chosen to host the corresponding payload model and, in DMS based trainers, to 
maintain direct access to MDM signals. 


Core Data 
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Figure 3.2-8 Core System Model Options 
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Figure 3.2-9 SCS C&D Connection Options 
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3. 2.7.4 Audio/Video System Options 

Where necessary, the audio and video systems are interfaced to the C&T 
portion of the Core systems representation to allow audio and video data to be 
formatted and merged into a trainer's telemetry data stream. High Rate Link data 
streams are assumed to be pre-formatted and to interface directly from the payload 
representation to the C&T processor/controller. 

The audio and video systems in each SCS design are implemented using 
standard intercom stations, CCTV cameras, tape recorders, and optical disks under 
computer control. Additionally, computer generated speech synthesis, voice 
recognition, and graphic imagery are provided by coprocessors or peripheral 
processors connecting to the trainer host. 

3.3 SCS Local Host Design 

In the Local Host design, a separate host computer is dedicated to each major 
trainer and facility. The design was formulated to: 

- use DMS kits and other SSF compatible components 

- accept flight equivalent payload hardware and 
software without significant modification 

- isolate and minimize the real time traffic loading on 
the SCS LAN 

- interface directly with SSF support systems, 
development systems, and communications systems. 

3.3.1 System Design 

A top level view of the detailed Local Host design is shown in Figure 3.3-1. The 
distribution of SCS functions across the computer hosts and other system components 
of the design is summarized in the SCS functional allocation matrix presented in 
Figure 3.3-2. Details of this design are addressed in the following paragraphs. 

3.3.1. 1 Network Architecture 

The Local Host design integrates the SCS using four types of LANs: 1) the SCS 
LAN which ties the separate facilities and trainers to central management and 
communications resources; 2) the Core LAN; 3) the Payload LAN within each DMS 
based trainer; and 4) the local LANs within each facility that connect workstations and 
terminals to their respective file servers. General specification of the network 
implementations is based on an initial analysis of the communications traffic and 
bandwidth requirements of the design. The results of this analysis are included in 
Appendix I. 

In the Local Host design, the traffic on the SCS LAN consists predominantly of 
file transfers and message traffic between the Training Session Manger, Instructor 
Workstations, and Trainer Host computers. Based on a profile of infrequent large 
block transfers and orderly message traffic across a limited number of nodes, a Token 
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Figure 3.3-2 Allocation of SCS Functions to Local Host Design 
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Ring implementation providing moderate throughput of 5-10 Mbps satisfies the 
anticipated communications loading. The contributing loads on this LAN are tabulated 

in Figure 3.3-3. 


The Core LAN and Payload LAN consist of the FDDI LAN, concentrators, and 
NOS included as part of the DMS Kit and, minimally, are functionally equivalent to 
their SSF flight counterpart. 


The use of local LANs within the CBT Facility and Development Facility support 
these workstation and file server configurations. The ^Ns support relatively low traffic 
loads accommodated within their 5-10 Mbps (CBT) and 10-20 Mbps (development) 
bandwidths, respectively. The advantage of a Token Ring implementation for these 
LANs is not implicit in the kind of large, and acceptably queued, file transfers that 
characterize much of their traffic. A Token Ring or Ethernet implementation achieving 
the necessary throughput can be used. 


The SCS support facilities and POIC trainers also connect to the SCS Netw o rk . 
In the case of the POIC Trainers, it should be noted that the telemetry feed is handled 
by a separate communications system and does not enter onto the SCS LAN. 


3.3.2 Trainer Design 

The Consolidated, Combined, and DMS Based Part Task Trainers introduced in 
Section 2.2 share the same essential architecture in the SCS Local Host design. The 
trainer designs are diagrammed in Figure 3.3-4, Figure 3.3-5, and Figure 3.3-6, 
respectively. Differences in the designs are due solely to the trainers 
configuration in respect to the number of labs and the number of payload experiments 
supported within a lab. One difference is that while the US Lab in the Consolidated or 
Combined Trainer is equipped with two crew consoles (MPACs), the remaining trainer 
labs have only one crew console. 

Replication of the Space Station DMS architecture in these trainers with DMS 
Kits offers the benefits discussed in Section 3.2. The approach also ensures that. 1 ) 
flight equivalent payloads will operate within the trainer; 2) payload models developed 
by the PTC for training are transportable to the SSTF more easily; and 3) Core 
systems models developed for other Space Station requirements can be used with the 

trainers. 


The Non-DMS Part Task Trainer design also shown in Figure 3.3-6 dedicat^ a 
workstation to serve as both the crew console and the primary computing platform. The 
workstation hosts the simulation executive, payload models, core models, and controls 
audio and video generated by an attached coprocessor. Payload mstmments ar ® 
interfaced using attached I/O adapters. The workstation connects to the SCS LAN and 
provides appropriate feeds (High Rate Link and Payload data) for a telemetry system. 


3.3.2.1 Host Architecture 

Each DMS based trainer relies on a dedicated local host - co n ne cted to B 
-- to support all realtime simulation functions not provided within the DMS-SIB 
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Figure 3.3-3 Local Host Network Loading 
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Figure 3.3-4 Local Host Consolidated Trainer Design 
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Figure 3.3-5 Local Host Combined Trainer Design 
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Figure 3.3-6 Local Host Part Task Trainer Design 
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complement The Trainer Host provides the processing for: 1) the simulation executive 
governing real time functions; 2) configuration, setup, and initialization support to the 
Training Session Manager (TSM); 3) payload, core, and environment mode 
execution; 4) audio/video control; 5) data base access 6) data/event recording, 7) 
device stimulation and GSE control; and 8) local diagnostics. 

The Simulation Executive synchronizes scenario, payload model, core model, 
and data base execution in the host with DMS/OMA software execution in DMS Kit 
SDPs. Synchronization with, and control of, the DMS complement is mediated 
through the SIB. The Simulation Executive monitors system status, simulation session 
status and student actions, and allows student console and panel views to be 
repeated on the Instructor Console. Through the SIB, the executive controls trainer 
operation including start, stop, step, freeze, sequence, and replay modes. It a so 
synchronizes the interface between simulation execution and peripheral devices 
including the Audio and Video Systems and payload C&D panels. The Simulation 
Executive reports system configuration and simulation session status to the Training 
Session Manager. 

The Trainer Host executes all payload simulations used in lieu of actual flight 
equivalent payloads. This simulation involves the simulation model software 
developed for that payload experiment and the C&D panel configured accordingly. 
The software is executed on the host to which the C&D panel is attached. If a payload 
normally generates video, the model based generation is controlled by the host using 
a processor attached video adapter. The host also controls other audio and video 
generated or replayed by the Audio and Video System diagrammed in Figure 3 . 2 - 2 . 

The Payload Simulation Host communicates with the SIB and its attached DMS 
components via a high speed bus channel link. It communicates with the Training 
Session Manager and other SCS training support facilities via the SCS Network. 

The OMA and network operating system (NOS) software furnished with the 
DMS Kit is hosted on a DMS SDP. Flight equivalent payload software may also run in 
SDPs or EDP-4s within other DMS components. The SIB is assumed to provide the 
necessary platform and software to effect control and synchronization of the DMS 
configuration. 

3.3.2.2 DMS Components 

The DMS components comprising the DMS based trainers are described in 
Section 2.3.1. DMS software including the Operations Management Application 
(OMA), Network Operating System (NOS), and the DMS Standard Services are 
executed in the DMS SDP. Core systems are represented by simulation models 
running on the DMS The DMS components support the connection of flight equivalent 
payloads to the DMS. It is assumed and has been depicted in Figures 3.3-4 and 3.3-5, 
that flight equivalent payloads interface to the DMS through an MDM. Provided that 
the payload instrument is equipped with other interface capabilities such as a BIA or 
NIU, the trainer design will also accommodate these alternative modes of connection. 
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When payloads that normally generate video (or optical scenes) are simulated, 
the video signal is reproduced by the Audio and Video System depicted in Figure 3.2- 
2. The signal may be derived from a video source and/or computer generated 
imaaery Generated images are obtained from a video/graphics adapter attached to 
the Trainer Host. Similarly for audio signals replicating voice communications, the 
sianal is reproduced from recorded media or generated by an attached audio adapter. 
When any computer generated audio and video presentations are required within the 
trainers they are routed from the Trainer Host directly to crew consoles instructor 
console’s, and other monitors. In the Local Host configuration, the trainer host serves 
as the host portion of the Audio and Video System depicted in the Figure 3.2-2. 

The C&T system simulator accepts uplink data and downlink data and 
processes it before putting it on the Payload LAN or routing it to POIC Trainers or the 
POIC Hiqh Rate Link data and concurrent Payload LAN data generated by flight 
equivalent payloads or by payload models are merged to form a telemetry stream. To 
encode dynamic video into such a downlink feed, the original signal is obtained from 
the Audio and Video System. Moderate rates of combined data may be processed by 
the C&T simulator to produce a realistic dynamic telemetry stream. High rates of 
dynamic data approaching SSF bandwidths require the processing of an external 
telemetry system (i.e. , the C&T processor/controller described in Section 3.2.2). 

The C&T processing typically involved in a lab trainer simulation session is the 
model based representation of the flight-ground information exchange. The model 
need only insure that the logical content of relevant communications and telemetry, 
and transmission characteristics affecting data receipt, be preserved. This level of 
representation is assumed to be achieved by the rudimentary C&T model incorporated 
in the Core models. The production of full capacity dynamic telemetry streams, 
however, requires additional model fidelity and processing to derive controlling data 
that drives high speed data generation sources such as the video subsystem. Full 
telemetry representation sufficient to drive the POIC/POIC trainers also requires the 
real time merging, formatting, and transmission functions emulated by the C&T 
processor/controller. The additional processing requirements of the high fidelity C&T 
and driver functions are reflected in the host loading tables that appear later for the 

SCS designs. 


When flight equivalent instruments are used as the payload device, the 
instrument is electronically and physically driven, or excited, by a Payload Stimulator 
The stimulator is configured and programmed to provide the excitatory signals and 
other stimuli necessary for the payload to function approximately as it would in space, 
and respond realistically to environmental inputs and manipulations arising out of the 
simulation scenario during a training session. The stimulator also controls the supply 
of GSE services (from a non-SCS PTC facility) that are necessary for the device to 
function appropriately. The stimulator is a processor based I/O adapter/controHer plus 
the required effectors/actuators that attach to the payload instrument. A Payload 
Stimulator also generates the electronic signals necessary to emulate the GPS input 
to the TGU in DMS based trainers. 


The stimulator is connected (using an RS-232 or SCSI interface) directly to, and 
under the control of, the Trainer Host (or workstation in the Non-DMS Part Task 
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Trainer) The stimulator responds to lab systems and Core systems models, in 
conjunction with specifications in the payload model, which in turn are driven by 
scenario events, ad lib control events, and outputs of the environment model. 


Finally, it should be noted that in all DMS based trainers in the Local Host 
desiqn the TDB has been implemented explicitly in the trainer diagrams. This 
implementation, under the current DMS Kit specification, is not actually necessary. 
The TDB can be eliminated because the SIB, connected directly to the TGU, assumes 
the bus function of distributing TGU (or equivalent) timing signals to the individual 
DMS components. It was elected, however, to represent the bus separately in case 
SIB functionality changes and provides timing function backup. 


3.3.2.3 Trainer Connectivity 

Trainer connectivity is implemented in varying degrees throughout the Local 
Host Desiqn. The greatest connectivity exists within the Consolidated Trainer. All 
trainers are interconnected only by the SCS LAN which, in this design, is intended to 
carry a minimal amount of real time simulation traffic. 


3.3.2.3.1 Consolidated Trainer 


The Consolidated Trainer has three means of connectivity across its three 
constituent labs: 1) Payload LANs; 2) common Timing Generation System and 
Distribution Bus (TDB); and 3) common Core models. At present, the " atl i r f ° f A h ® 
LANs to be employed in the Columbus and JEM labs is not known^ The DMS Kits 
incorporate gateways between the US lab and the other labs. If the Payload LANs of 
the Columbus and JEM labs are compatible with the OSI layers 1 and 2 adopted by 
the FDDI protocol, the gateways may be replaced with bridges. 


The Consolidated trainer relies on a common Simulation Executive hosted on a 
sinqle computer to supervise all three labs. The processor hosts all payload models. 
Generation of the trainer's audio and video for the labs is also under the control of this 
host. The Columbus and JEM labs are connected to the host through an 
undetermined interface identified in the figures as a Trainer l/F. 


Core models run on DMS Kits. The C&T processor/controller performs the C&T 
processing required and is utilized via a patch panel to connect to the consolidated 
trainer, as well as all other trainers. 


3.3.2.3.2 Other Trainers 

The Combined Trainers and Part Task Trainers operate independently and are 
only interconnected through the SCS LAN. Each trainer, including the Non-DMS Part 
Task Trainers, relies on a dedicated LAN for primary connection. In addition to the 
component connectivity provided by the payload LAN for all trainers, except for the 
non-DMS PTTs, the SIB adds additional connection paths to the DMS based trainers. 
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3.3.3 Host Loading 

Host loading for the Local Host Design is based on estimated maximum 
loadings of the SCS. It was assumed that all trainers were in operation concurrently 
with a full level of software development activity. The capacity in Mips of the general 
purpose hosts comprising the Local Host Design is tabulated in Figure 3.3-7. The 
figure summarizes the estimated computational resource in Mips required to execute 
each of the basic SCS functions identified in the function allocation matrix presented 
earlier in Figure 3.3-2. Appendix I has been included to provide more details on the 
assumptions and methods underlying these estimates. 

The Trainer Hosts in this design have maximum computing capacities ranging 
from approximately 20 Mips for Part Task Trainers to 38 Mips for the US Lab 
Combined Trainer and 60 Mips for the Consolidated Trainer. 

The host sizing to support the various SCS facilities common to all SCS 
designs are presented once in this table. The substantial Mips requirements to 
support the Development Facility stems from a heavy reliance on high fidelity payload 
models. The distributed modular design of this facility, however, yields a large number 
of relatively small platforms allowing easy incremental implementation of the full 
facility. 

3.4 Shared Host Design 

The Shared Host design is comparable to the Local Host Design in most design 
respects beyond the architectural difference in the basic deployment of, and access to, 
the Simulation Hosts that replace the previous design's Trainer Hosts. The objectives 
of the Shared Host design goals were to: 

- achieve flexibility in application and usage of host computers 

- use DMS Kits 

- accept flight equivalent H/W 

- interface directly with SSF support systems 

- improved reconfigurability 

- maximum use of SCS LAN. 

3.4.1 System Design 

The Shared Host design meets SCS requirements and achieves SCS 
objectives by using an architecture which permits the SCS processing load from all 
trainers to be shared among multiple hosts instead of allocating a fixed load to 
dedicated hosts. All SCS facilities, other than the actual lab trainers and the Training 
Session Manger, are implemented in the same manner as the Local Host design. 

The distinguishing characteristic of the Shared Host Design is that the trainer 
hosts do not reside in the individual Combined, Consolidated, and DMS Part Task 
trainers, but rather on the SCS Network. A small number of general purpose hosts 
reside on this LAN and are shared by the eight DMS based trainers. Six hosts have 
been specified: five for simulation and one for the Training Session Manager and 
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Figure 3.3-7 Local Host Loading 
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external communications. These hosts share the processing load between them, with 
no fixed allocation of a host to a specific trainer. In keeping with the SCS Conceptual 
Design Report, these hosts are referred to as Simulation Hosts. 

A top level view of the Shared Host design is presented in Figure 3.4-1. The 
allocation of SCS functions to design components in the Shared Host design is 
tabulated in Figure 3.4-2. 

3.4.1. 1 Network Architecture 

The Shared Host design employs four types of LANS: 1) the SCS LAN 
connecting trainers to hosts and interconnecting the SCS facilities; 2) the Core LAN 
which interconnects the core SDP and the SIB; 3) the Payload LAN, which 
interconnects the DMS components and the SIB; and 4) the local LANS within eac 
facility connecting workstations and terminals to their respective file servers. 

In contrast to other designs, the traffic on the SCS LAN is predominantly real 
time data exchanged between the DMS based trainers and their simulation models 
executing on the shared Simulation Hosts. Based on initial estimates compiled in 
Appendix I, the expected maximum load on the LAN is 71 Mbps. The estimate is 
within the bounds of FDDI Token Ring networks which offer the added advantage of 
being compatible with the projected FDDI implementation of the SSF DMS Core and 
Payload LAN. Further, the short synchronous message character of simulation 
exchanges favors a Token Ring implementation. The contributing loads on this LAN 
are tabulated in Figure 3.4-3. 

Except for the Non-DMS Part Task Trainer, trainer types connect to the SCS 
LAN through their respective SIBs. In the Non-DMS trainer, each trainer workstation 
connects directly to the SCS LAN. 

The SCS support facilities and POIC trainers also connect to the SCS Network. 
In the case of the POIC Trainers, it should be noted that the telemetry feed is handled 
by a separate communications system and does not enter onto the SCS LAN. 
Similarly, the High Rate Link communications in other trainers is isolated from the 
Payload and SCS LANs on a separate communications system. The use of local 
LANs within the CBT and Development facilities support the related workstations 
configurations and their interconnection to the file servers. The estimated bandwidth 
for these LANs is the same as presented for the Local Host design in Section 3.3.1 .1 . 

The Core and Payload LANs are both FDDI networks. The Core and Payload 
LAN will be modeled after the SSFP flight LANs to connect the various DMS 
components and, in some cases, payloads. It is assumed that both Core and Payload 
LANs are included in the DMS Kit. 

3.4.2 Trainer Design 

The Shared Host trainer configurations of DMS components (or workstations in 
the Non-DMS Part Task Trainer) are the same as in the Local Host trainers except that 
the video portion of the Audio and Video System is implemented differently. The 
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Figure 3.4-1 Top Level View of Shared Host Design 
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difference -- necessary to detach this function from the remote host implementation -- 
is described below. A further difference arises in the interface between the Training 
Session Manager and individual Simulation Executives. The potential integration of 
these functions (TSM and Simulation Executives) on a common host reduces network 
traffic and increases overall efficiency. The DMS Core SDP runs the flight equivalent 
OMA and core models. The Shared Host trainer types are diagrammed in Figure 3.4-4 
through Figure 3.4-6. 

Each trainer is supported by two or more hosts accessed on the SCS LAN and 
shared with other trainers. This means that time sharing or parallel execution of TSM 
and simulation executives, as well as simulation models, is performed on a host. The 
allocation of hosts and functions indicated in Figure 3.4-2 is somewhat arbitrary and is 
easily reconfigured. Indeed, one of the advantages of the Shared Host design is the 
level of fault tolerance that can be gained by dynamically reallocating functions when 
a host is overloaded or failing. 

In contrast to other designs, the Shared Host DMS Part Task Trainers share one 
SIB. This is an assumed possibility that would add flexibility to the SCS design, and is 
not the current SIB baseline. This option's availability thus depends on the final SIB 
design, and could also be implemented within the Local Host design. A trainer’s DMS 
components and the Core systems models, however, remain exclusive to the 
individual trainer. The trainer connectivity is discussed further in a later section. 

3.4. 2.1 Host Architecture 

The Shared Host design is depicted consisting of five hosts. While the number 
is preliminary, initial estimates of computing resource requirements and the 
distribution of simulation and training functions confirm the reasonableness of this 
selection. This bank of comparable hosts is used to support all real time simulation 
functions not provided within the DMS-SIB complement, and all TSM and other non- 
real time training facility functions. In order to support reassignment of trainers, 
reallocation of simulation functions, and load balancing, the hosts run the same 
operating system and share common disk storage. 

In addition to their interconnection via the SCS LAN, the shared hosts are 
provided with a common high speed channel connected to a dual configuration of file 
servers. This sharing of disk storage keeps SCS LAN traffic from mushrooming with 
simulation data base activity. The disk storage is expected to maintain the virtual 
memory SCS global data base for all training sessions, as well as configuration, 
initialization, and environment data bases. Other benefits of this configuration include 
enhanced system backup and recovery capabilities, and a basic capacity for fault 
tolerant operation by taking advantage of the redundant file servers and disks. 

The Simulation Executive synchronizes scenario, payload model, and data 
base execution in the host with DMS/OMA software execution in DMS Kit SDPs. One 
Simulation Executive for each active trainer is executed on one of the shared hosts. 
Besides coordinating DMS, SIB, and model driven activity in real time, a Simulation 
Executive provides access and logging capabilities to enable instructor control and 
status reporting to the Training Session Manager, residing on a shared 
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Figure 3.4-5 Shared Host Combined Trainer Design 
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host localized for non-real time processing. The simulation synchronization scheme 
proposed for all SCS designs in Section 3.2.6. 1 provides the means to sustain an 
efficient exchange of simulation data between the shared hosts and the trainers. 

3. 4. 2. 2 DMS Components 

The DMS components described in Section 2.3.1 are employed in this design 
similarly to the Local Host design as described in Section 3.3. 2. 2. A dedicated 
processor/controller is utilized to perform the C&T system simulation, just as was done 
in the Local Host design. This configuration stems from the requirement to provide 
downlink data streams from individual lab trainers as part of the telemetry data 
exchange with the ROIC and POIC Trainers. The close interface with a specialized 
telemetry system (when full bandwidth emulations are necessary) and with the 
trainer’s audio and video systems prevents a remote shared host implementation of 
the C&T capability. High Rate Link data generated by flight equivalent payloads or by 
payload models are merged with payload data to feed the external telemetry system. 

To encode dynamic video into such a downlink feed, the original signal is 
obtained from the Audio and Video processor/controller connected to the Payload 
LAN. This specialized processor/controller includes processor attached audio/video 
adapters and frame buffers providing direct feeds to SCS systems. When any 
computer generated audio and video presentations are required within the SCS 
Shared Host trainers, it is routed from the process/controller directly to crew consoles, 
instructor consoles, and other monitors. It serves as the host portion of the Audio and 
Video System depicted in Figure 3.2-2. 

As in all DMS based designs, flight equivalent payloads typically interface to the 
DMS through an MDM. When payload models are used in lieu of flight articles in the 
Shared Host design, the simulation software is executed on the shared hosts. The 
C&D panels associated with the payload, however, are connected to the DMS through 
the Local Bus, rather than to a trainer host in the Local Host design. The Payload 
Stimulator described previously in Section 3. 3. 2. 2 for the Local Host design is also 
compatible with this design. In the Shared Host design, however, the stimulator 
attaches to the Local Bus instead of the trainer host. 

3.4.2.3 Trainer Connectivity 

Trainer connectivity is similar to that found in the Local Host SCS except that 
inter-trainer connectivity is facilitated by the fact that software functions for different 
trainers reside on the same host. Thus, connectivity is achieved in the form of 
interprocess communications among executive function and simulation function real 
time applications. These communications, although not needed to meet currently 
specified SCS requirements, could be used to meet future implementations affording 
reconfigurability across trainers. For example, this mode of communications is one 
way to drive all trainers with a common scenario and data base. 

Another approach to increased reconfigurability, which is not shown in the 
figures, is to connect directly to each trainer's Payload LAN via gateways or bridges to 
the SCS LAN. This would connect independent trainers comparably to how the 
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Consolidated Trainer is implemented, allowing three Combined Trainers to be 
reconfigured and serve as the consolidated labs trainer. The connection also 
achieves a level of fault tolerance and additional flexibility by providing an alternative 
path between host and DMS which bypasses the SIB. The latter feature would apply 
equally well to an SCS Local Host implementation. 

The SIB's connection directly to the SCS LAN, instead of to a host computer, 
adds the proper (FDDI) network interface as a requirement to the SIB furnished in the 
DMS Kit. This is not the current SIB baseline, however, Lockheed indicated a FDDI 
connection refinement was being considered. This is different from the high speed 
processor bus channel used to connect the SIB to the Trainer Host in the Local Host 
design. 

3.4. 2. 3.1 Consolidated Trainer 

As in the local host design, the Consolidated Trainer has four means of 
connectivity: 1) Payload LANs; 2) Core LAN; 3)common Timing Distribution System 
using the Timing Distribution Bus (TDB); and 4) common Core models running on a 
shared host. This trainer also uses a common processor/controller for C&T 
processing. The path for Core data and payload data to the Columbus and JEM labs 
is the Core and Payload LAN gateways to their respective lab trainer networks, as 
illustrated in Figure 3.4-4 

3. 4. 2. 3. 2 Other Trainers 

As with the Consolidated Trainer, the connectivity of the Shared Host Combined 
Trainer and the Non-DMS Part Task Trainer is essentially the same as that found in 
the Local Host design. 

In contrast to other designs, the DMS Part Task Trainers take advantage of the 
SIB's assumed capability to directly support multiple units of each DMS component. 
Consequently, the hosts' SCS LAN connection to a single SIB fans out through the 
SIB’s multiple DMS links to several Payload LANs, each integrating a suite of DMS 
components to represent a separate part task trainer. Independent Simulation 
Executive, Core model, and payload model processing are maintained on the shared 
hosts. The obvious advantage of this approach is the reduction to one the number of 
SIBs required to implement the four trainers. 

While the workstation of the Non-DMS Part Task Trainer resides on the SCS 
network, these trainers do not use the shared hosts for real-time simulation 
processing, relying on them only for Training Session Management functions. 
Regardless, the option exists to use the shared hosts for real time processing if 
necessary. The same arrangement and option exist, with the addition of some 
software, for the POIC Trainers 

3.3.2.3.3 IT&V Facility 

The IT&V Facility, based on the design of the Combined Trainer, depends on 
the shared hosts for its Simulation Executive, some Core models, and payload model 
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executions. The connectivity with the Development Facility on the SCS LAN, permits 
software models to be uploaded directly to the facility’s corresponding hosts. 

3.4.3 Host Loading. 

Host loading for the Shared Host Design is based on estimated maximum 
loadings of the SCS. It was assumed that all trainers were in operation concurrently 
with a full level of software development activity. The capacity in Mips of the general 
purpose hosts comprising the Shared Host Design is tabulated in Figure 3.4-7. The 
figure summarizes the estimated computational resource in Mips required to execute 
each of the basic SCS functions identified in the function allocation matrix presented 
earlier in Figure 3.4-2. Appendix I has been included to provide more details on the 
assumptions and methods underlying these estimates. 

The five shared Simulation Hosts in this design each have maximum computing 
capacities of approximately 30 Mips. The Non-DMS Part Task Trainers are hosted by 
workstations with a maximum required capacity of 20 Mips. 


3.5 DMS Equivalent Design 

The basic architecture of the SCS DMS Equivalent design is consistent with the 
architecture of the Local Host design. The trainer implementations, ho 'f / f'^ er ’ 
distinguished by not employing the DMS Kits. The design objectives of the DMS 
Equivalent design include the following: 

achieve sufficient DMS function without relying on SSF flight equivalent 
components 

distribute processing requirements across standard inexpensive 
computer platforms 

minimize centralized SCS LAN traffic loads 

maintain SSF DMS compatibility to interface DMS components and 
software 

maximize reconfigurability 

3.5.1 System Design 

The DMS Equivalent design addresses SCS objectives by adopting a 
distributed processing implementation in the trainers using standard commercial 
hardware. The design replaces the flight equivalent DMS components of the previous 
trainer designs with commercial general purpose microcomputers and custom 
software. The SIB and Trainer Host are also replaced by these general purpose 
microcomputers tied together on a trainer LAN. This network replaces the Payload 
LAN and other DMS/SIB busses. A top level view of the DMS Equivalent Design is 
shown in Figure 3.5-1. The allocation of SCS functions to the DMS Equivalent Design 
is shown in Figure 3.5-2. 

The design, while straight-forward to implement, presents certain challenges. 
Although the necessary hardware should be inexpensive, the potential cost of custom 
software, if the commercial hardware cannot support SSF flight equivalent software 
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Figure 3.4-7 Shared Host Loading 
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Figure 3.5-1 Top Level View of DMS Equivalent Design 
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Figure 3.5-2 Allocation of SCS Functions to DMS Equivalent Design 
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without major modification, could be substantial. Also, changes in the SSF 
specification and design will necessitate close tracking of program upgrades to the 
SSF software and hardware. 

3.5.1 .1 Network Architecture 

The DMS Equivalent design contains three types of networks: 1) the Trainer 
LAN which connects all the processing and I/O components comprising a trainer; 2) 
the SCS LAN which interconnects the trainers and other SCS facilities; and 3) the 
Local LANs of the Development Facility and CBT Facility. 

The Trainer LAN is the backbone of each trainer. This network bears all real 
time simulation traffic among the attached microcomputers supporting payload 
models, environment models, Core models, and the Simulation Executive, as well as 
the payioad instruments and I/O devices. 

The average and maximum traffic loads on the Trainer LAN depend directly on 
the nature of the (actual or simulated) payload. The payload data 
acquisition/generation rates possible for a single payload experiment create a wide 
range of possible loads on the Payload LAN representation. Disregarding for the 
moment any substantial data output, the total simulation traffic on the Trainer LAN can 
be estimated to vary between 3 Mbps in the Part Task Trainer and 13 Mbps in the 
Consolidated Trainer, based on the number of payloads under active control. If the 
aggregate of the 48 actual onboard payloads modeled by the SCS were active 
onboard the in orbit SSF at the same time, and were all sending data even a moderate 
rate, the FDDI 100 Mbps would not be fast enough. If the aggregate of 48 active 
payloads in the Consolidated Trainer were active in the SCS, the same approach to 
the 100 Mbps limit of a FDDI network implementation would be made. Thus the SCS 
is limited in the number of active payloads, but this limitation mirrors the actual SSF 
design. The contributing real time loads on the Trainer LANs are tabulated in Figure 
3.5-3. 


The SCS LAN is similar in function to the Local Host design supporting the 
Training Session Manager (TSM) link to all trainers and the interconnection of the 
other SCS facilities. The traffic on the LAN is primarily file transfers during 
configuration and initialization, and instructors' interaction with the trainers through 
their respective Simulation Executives. The maximum required bandwidth to support 
bulk transfers (which can be queued) and TSM message exchange is estimated at 
approximately 4 Mbps. The undemanding character of these data communications 
suaqests that any Ethernet or Token Ring network implementation will be satisfactory. 
The real time and non-real time contributions to the SCS LAN loading are also shown 

in the figure. 

The Local LANs in the Development and CBT are identical to other SCS 
designs and have been described previously. 
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Figure 3.5-3 DMS Equivalent Network Loading 
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3.5.2 Trainer Design 

The Consolidated, Combined, and Part Task Trainers have essentially the 
same architecture in the DMS Equivalent design. Differences between the trainers 
arise in how they are used and the number of payload experiments they support. The 
DMS Equivalent trainer designs are shown in Figure 3.5-4 through Figure 3.5-6. 

Trainers in the DMS Equivalent approach distribute DMS and payload functions 
across several microcomputers residing on their Trainer LAN. The functions are 
simulated or emulated using standard computer platforms, I/O devices, and LAN 
systems, and custom simulation software. Relying solely on the LAN for all DMS 
component communications, means that a greater portion of these communications 
are centralized in DMS simulation models. It also means that the low level control 
functions provided by the SIB are implemented at a higher level across the Trainer 
LAN whenever this control actually spans separate DMS Equivalent microcomputers. 

The payload instruments, C&D panels, Audio and Video System, Payload 
Stimulator, and other devices and software remain the same as described previously 
for other SCS designs. In the case of the crew console, the workstation adopted for 
the non-DMS Part Task Trainers in previous designs is used through out the DMS 
Equivalent design instead of flight equivalent MPACs. The instructor stations are 
located on the SCS LAN and communicate with the Simulation Executives under the 
supervision of the TSM. 

While the goal of the DMS Equivalent trainer design is to achieve the same 
level of useful SSF payload compatibility as do other SCS designs, its success 
depends on final DMS Kit capabilities. Regardless of the level, this design can 
achieve compatibility at a savings by eliminating the development and hosting of many 
high fidelity SSF representations. Environment representations necessary to enable 
the operation of a complete DMS in order to support payload models and flight 
equivalent instruments are large and costly to host. Most representations of Core 
systems, the environment models and data bases that drive them, and some DMS 
systems are not deemed necessary to support payload operations in a simulation 
environment. These representations are necessary only when the full complement of 
actual DMS components must be driven to perform accurately and in concert with one 
another. 

It is expected that flight equivalent software will require modification to run in 
this environment. Also, payload models developed for this environment will require 
modification to run in DMS based trainers. 

3.5.2. 1 Host Architecture 

The intent of the trainer design is to use general purpose microcomputers to 
recreate the essentials of the DMS that are necessary to operate payloads to meet 
training objectives. The viable host architectures are those that are compatible with 
the SSF DMS components. This compatibility can be achieved at a useful level, for 
example by selecting computer platforms using the same (or microcode compatible) 
CPU as SSF articles (e.g., Intel 80386). Further compatibility can be achieved by 
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Figure 3.5-4 DMS Equivalent Consolidated Trainer Design 























High Rate Link 


TRW-SCS-89-T5 


Refined Design 6 8 



Figure 3.5-5 DMS Equivalent Combined Trainer Design 
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Figure 3.5-6 DMS Equivalent Part Task Trainer Design 
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selecting on the basis of the processor's backplane bus (e.g., Multibus II) and 
operating system support. Attaining these levels of compatibility will establish the 
ease of recreating SSF-like system applications, and the ease of actually porting SSF 
code modules to SCS trainer microcomputers. 

The Consolidated Trainers and Combined Trainers incorporate five (or more) 
microcomputer platforms in place of a host for: 1) the Simulation Executive and file 
services; 2) the TGS model; 3) audio and video generation; 4) the Core and 
environment models; and 5) the payload models. When the number of payload 
models is high, such as in the US Lab Combined Trainer, two (or more) payload 
microcomputers are included. Also, the workstations support the processing 
necessary to emulate required MPAC functions. The microcomputer platform hosting 
the Simulation Executive provides a network interface to the SCS LAN and the TSM. 

The Part Task Trainers are all implemented with the same non-DMS 
architecture. They differ from the other DMS Equivalent trainers only in the number of 
distributed microcomputers that are dedicated to run simulation models. This 
consolidation of computing resources is due to the significantly fewer payloads that 
are supported concurrently during part task training and the commensurate reduction 
in the scope of DMS component representation necessary to maintain appropriate lab 
fidelity. The Part Task Trainer also distributes Core model execution onto the 
workstation used to represent the MPAC, reducing the number of dedicated general 
purpose computers to three. 

3.5.2.2 "DMS" Components 

DMS component (hardware and software) functions are simulated or emulated 
using commercially available standard microcomputer systems and the necessary 
simulation software. The functional fidelity of the DMS simulation is comparable to 
DMS Kit capabilities within the strict domain of payload training objectives. This 
means that some functions supported by the Kit that relate to Core and other non- 
payload systems may not be implemented. This restriction shall not, however, 
diminish the capability to interface actual flight equivalent payloads and related DMS 
components within the trainer to support training objectives. Component interfacing 
will typically be supported with appropriate I/O devices attached to the processor bus 
of the microcomputers. 

The Part Task Trainer type incorporated in the DMS Equivalent design only 
simulates the DMS payload environment. The trainer's computer platforms, including 
the workstations used to represent the MPACs, host a complement of DMS simulation 
models necessary to ensure sufficient lab fidelity for payload training. No direct 
emulation of individual DMS components is undertaken. 

3.5.2.3 Trainer Connectivity 

The computer platform which hosts the Simulation Executive for each trainer 
type includes a network interface to attach the trainer to the SCS LAN. This 
configuration serves to isolate each trainer on the SCS LAN, but is not a necessary 
feature of the design. Instead, network bridges could be used to link individual trainer 
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LANs to the SCS LAN. This alternative would reduce the protective level of isolation 
among trainers and the SCS while increasing the degree of reconfigurability across 
trainers. 

3.5.2.3.1 Consolidated Trainer 

The Consolidated Trainer uses the Trainer LAN to link the US lab, Columbus 
lab and JEM lab. For current design purposes, the Columbus and JEM labs were 
implemented in a manner functionally like the US lab. The same architecture is used 
to support payloads while sharing all of the space station representations in common. 
Consequently, four of the five US lab microcomputers are shared to provide the 
Simulation Executive and file services, TGS and C&T models, audio and video 
generation, and Element Core, and environment models. The labs Trainer LANs are 
connected with gateways as depicted in Figure 3.5-4. This configuration serves to 
isolate the Columbus and JEM labs from one another, but is not a necessary feature of 
the design. A single Trainer LAN could be employed to implement all three labs. This 
approach, however, would not achieve a representation of the actual SSF lab 
interconnectivity which is mediated with gateways. 

3.5.2.3.2 Combined Trainer 

Connectivity in the Combined Trainer is comparable to the connectivity 
implemented in one lab of the Consolidated Trainer. The replacement of the host 
attachment to the SCS LAN with a bridge to the trainer LAN would allow these trainers 
to share a single Core and environment representation under one Simulation 
Executive. The arrangement would allow the three trainers to serve temporarily as a 
Consolidated Trainer. 

3.5.2.3.3 Part Task Trainer 

Part Task Trainer connectivity is, aside from fewer distributed microcomputers, 
comparable to the Combined Trainer. The replacement of the host attachment to the 
SCS LAN with a bridge would allow these trainers to share their distributed 
microcomputers in order to, for example, temporarily expand the capacity of one Part 
Task Trainer to support an additional number of payloads. 

3.5.3 Host Loading 

Host loading for the DMS Equivalent design is based on estimated maximum 
loadings of the SCS. It was assumed that all trainers were in operation concurrently 
with a full level of software development activity. The capacity in Mips of the general 
purpose microcomputers comprising the SCS DMS Equivalent design is tabulated in 
Figure 3.5-7. The figure summarizes the estimated computational resource in Mips 
required to execute each of the basic SCS functions identified in the function 
allocation matrix presented earlier in Figure 3.5-2. Appendix I has been included to 
provide more details on the assumptions and methods underlying these estimates. 

The SCS TSM host in this design has an estimated maximum required 
computing capacity of 16 Mips. The various types of trainers are comprised of several 
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Figure 3.5-7 DMS Equivalent Loading 
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microcomputers each, ranging from approximately 3 Mips to 8 Mips each for the 
payload microcomputer(s) in a Part Task Trainer and the Consolidated Trainer, 
respectively, and 5 Mips to 12 Mips each for the other dedicated microcomputers in a 
trainer. 


4.0 SCS Design Comparison 

The SCS designs described in this document share many similarities in spite of 
their different architectures. The common and the unique features characterizing 
these designs have been detailed in previous sections. Design implementations have 
also been contrasted in terms of their efficiency and performance. In the present 
section, the relative advantages and disadvantages of the designs are summarized. 

Contrasts in performance and value associated with the designs are a 
consequence of a limited set of differences among the SCS designs. Each design 
satisfies the SCS functional requirements tabulated in the Function Allocation Matrices 
of Sections 3.3, 3.4, and 3.5. The principal SCS design differences are identified in 
Figure 4.0-1. 

The design process and the present comparison of designs can consider 
several factors indicative of system performance and value. The following factors, 
where applicable, have been considered in assessing the relative merits of each 
design. 

* Reliability and maintainability 

* Expandability and scalability 

* Cost (cost to build, life cycle cost, and schedule risk) 

* Computing headroom 

* Hardware/software standards 

* Reconfigurability and modularity 

* Ease of operation 

* Performance/functionality versus cost 

In all SCS designs, cost, performance, modularity and reliability have been the 
predominant considerations. The design differences summarized in the figure reflect 
the attempt to formulate designs that maintain a favorable balance of these factors. 

4.1 Reliability and Maintainability 

The trainers in the Local Host and Shared Host designs rely on DMS Kits. 
Assuming the DMS Kits implement the fault tolerant redundancy features of 
preliminary SSF DMS specifications and adopt SSF quality assurance controls, DMS 
based trainers should enjoy high levels of reliability. 

The DMS Equivalent design should have a reasonably high reliability since it 
will use off-the-shelf components. In addition, off-the-shelf components will potentially 
have better maintainability over DMS components since they are standardized 
commercial products which will have readily available maintenance services and 
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Figure 4.0-1 . Summary of Design Differences 
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nearby inexpensive spares inventory. The maintainability of DMS Kit s and the SIB 
may be dependent on specialized resources. 

The lower host platform count in the Shared Host design lends a certain 
advantage to the design in respect to system reliability. The aggregate system-wide 
incidence of failure, which is largely a function of equipment count and robustness of 
the equipment, should decrease with the Shared Host's dependence on fewer and 
larger platforms. Maintainability is often improved with large platforms because they 
incorporate more internal diagnostics. When many small platforms are used and are 
the same, maintainability is facilitated by the replaceability of any platform with another 
unit. 


The Local Host design would have a reliability much like the PCTC. 
Maintainability would be good since, except for the DMS Kits, commercial equipment 
could be used. 

Software reliability is greater in the designs where Space Station Freedom 
software can be used. It is assumed that DMS Kit software and SSE or equivalent 
simulation model software will reflect the reliability benefits of program test, validation 
and wide-spread use of SSF simulation software. 

4.2 Expandability and Scalability 

The DMS Equivalent design has an advantage over the other SCS designs in 
both the ease and cost of expanding its trainer configurations. The cost associated 
with designing the DMS Equivalent with DMS and other SCS functions distributed 
across numerous dedicated hosts is paid once in the original design effort. Expansion 
using this design via distribution and replication will only involve the cost of 
purchasing and installing hardware. The expansion of DMS based trainers may be 
hindered by the availability of multiple DMS Kit components and intrinsic limitations to 
expansion in the Kit hardware and software architectures. 

Further, the Shared Host design is more easily expanded than the Local Host 
design. The common platforms in the former design are assumed to be similar, if not 
identical. Similar computers can be added to this bank to assume the same 
processing tasks, such as payload model execution, as other platforms. This 
augments the resources available to all trainers without altering the basic 
configuration or incurring additional overhead beyond that already in place to manage 
the sharing of resources. 

Scalability is favored by the open architecture approach of the DMS Equivalent 
design which has the flexibility to accommodate computer platforms which can be 
scaled easily to provide specific levels of computing power. The same advantage can 
also apply to the custom simulation software of the DMS Equivalent design, if it is 
developed to support adjustable resolution, or detail, in a simulation. For example, 
modular structured simulation models can be incorporated to allow both abstract and 
detailed representations of DMS payload systems. Thus, the fidelity (and computing 
demands) of the model may be adjusted to match the fidelity of available data and the 
fidelity demanded by the desired training objectives. 
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4.3 Cost 

The cost considerations of system designs are multifaceted, often with one cost 
being offset by another associated cost. Costs for SCS include the: 1) cost to build 
hardware and software; 2) life cycle cost; and 3) schedule risk. The costs summarized 
below should be accounted for in any comparison of the SCS designs. 

Cost to Build 

Hardware costs for the SCS designs involve the cost of their general purpose 
computers, their flight equivalent hardware, and their trainer peripherals and other 
facility peripherals. For the most part, the peripherals and the computers supporting 
the ancillary SCS facilities are common across the SCS designs and their costs will 
be comparable. The cost of the general purpose computers supporting the trainers, 
however, differ for each SCS design. These hardware costs depend on the total 
computing horsepower required by the design, in Mips (millions of instructions per 
second), and the number and size of platforms used to deliver that total. The relative 
cost of appropriately sized computers varies with size in the approximate fashion 
depicted in Figure 4.3-1 . This table identifies several classes of computer platforms by 
size and their relative cost per Mips, where the cost of mainframe Mips is the reference 
(1.0). This data was generated originally as part of the Study Analysis Task (see A- 
6/A-8), and this table is an extrapolation of that data. 


Relative 


ComDuter Class 

Mips Range 

Cost/Mi ds 

Super 

100 - 

1000 

0.30 

Mainframe 

20 - 

120 

1.00 

Mini-Super 

50 - 

200 

0.25 

Super-Mini 

30 - 

80 

0.35 

Mini/Midi 

10 - 

40 

0.50 

Workstation 

6 - 

20 

0.15 

Micro 

1 - 

8 

0.10 

Figure 4.3-1 

Computer 

Platforms 


Hardware Cost 

A review of the computing requirements of each SCS design (appearing 
previously in Figures 3.3-6, 3.4-6, and 3.5-6) revealed a total trainer requirement of 
360 Mips for the Shared Host, 383 for the Local Host, and 429 Mips for the DMS 
Equivalent design. When these loads are distributed across the assigned computer 
platforms, the increased Mips of the DMS Equivalent design is more than offset by the 
lower per-Mips cost factor of the smaller Micro to Mini/Midi platforms (0.1 - 0.5). 

The DMS Equivalent design advantage is increased by the additional cost of 
the DMS Kit hardware of the other designs. Flight equivalent DMS components are 
not included in the accounting of general purpose host requirements in the sizing 
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analyses in Appendix I. This is because it is assumed that the DMS Kits will be 
designed such that they will be fast enough and large enough to support the 
necessary DMS OMA and other core software. 

The Local Host design relies on more platforms with an overall higher cost 
factor of Super-Mini to Mini/Midi (0.35 - 0.5). The resulting increase in cost reflects the 
concentration of functionality onto a dedicated trainer host. These hosts, for example, 
must accommodate a large number of I/O channels to support payload representation 
devices (i.e., C&D panels and payload stimulators). 

The Shared Host design, while needing the fewest Mips, tends to concentrate 
those Mips into the fewest machines (Mini-Super to Mainframe). This yields a 
computer platform cost factor of 0.25 - 1.0. The concentration achieved in the Shared 
Host design also means that a significant overhead is borne to manage the 
multitasking/multiprocessing environment needed to service multiple trainers and 
achieve load balancing. 

The unique consolidation of trainer communications on the SCS LAN yields 
traffic levels requiring a FDDI implementation of the network for all designs. The 
present cost per node of FDDI implementations is 6 -10 times that of Ethernet or other 
Token Ring network. While this premium is expected to drop significantly over the next 
few years, a significant cost differential will probably continue to exist. 

Software Cost 

The DMS Equivalent design entails the highest initial software development 
costs to cover custom DMS simulation models. The high cost reflects the assumption 
that flight equivalent software will not be used without significant modification, and the 
fact that SSF upgrades will have to be mirrored with new development. Conversely, 
these custom DMS models can be fashioned to integrate efficiently with payload 
models. Consequently, the DMS, Core, and payload models need only represent the 
variables and fidelity that are necessary for training objectives. There is no need, as 
with the DMS based designs, to accommodate full flight equivalent representations 
and associated space station simulation requirements. 

If, in addition to the DMS/OMA software, it is assumed that SSE Core models 
are available for SCS use, much less software will be needed to develop the Shared 
Host and Local Host designs. However, if SSF software is not available at the outset, 
the high fidelity models necessary to support flight equivalent hardware will exceed 
DMS Equivalent software requirements. 

Cost to Build SCS ROM 

A ROM is a rough order of magnitude estimate, generally accurate to plus or 
minus fifty percent. This ROM was constructed by applying a consistent cost 
methodology across the three very different designs, to provide a congruent cost 
estimate solely for the purpose of comparing the three designs in an objective manner. 
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First, an average was taken of the range of Mips cost factors for each design. 
This yielded an average Mips cost factor for each design. Next, a cost per Mips 
amount of $100,000 per Mips was selected. This seems high, but it is intended to 
cover not just the computer costs, but associated costs like the networks needed, 
graphics workstations, instructor workstations, and required COTS software. 
Multiplying the mean Mips cost factor by the Mips required by each design yields an 
adjusted hardware cost. Multiplying this by the cost per Mips gives a standard 
hardware cost ROM for each design. 

The costs to perform systems engineering, requirements analysis, design, code, 
test, and IT&v are estimated to be at an average base of approximately 2,500 man 
months (MM). Using a MM cost of $8,500 per MM, yields a base labor cost of $17M. 
For the Shared Host design, and additional factor of 10% is included to represent the 
increased complexity of a distributed design. For the DMS Equivalent design, it is 
necessary to add an estimated 100,000 lines of source code (SLOC) to cover the 
possibility that the core system models would need to be developed from scratch. At a 
production rate of 150 SLOC per MM, this translates into 666 MM, or $5.7M. 

Note that the cost of DMS Kits are not included in the ROM, nor are the PTC 
trainer hardware costs estimated, since these are considered GFE for SCS purposes. 
The summary of the cost to build is shown in the following table. 



Local Host 

Shared Host 

DMS Equi' 

Mean MIPS CF 

.425 

.625 

.3 

HA/V Cost Factor 

162.7 

225 

128.7 

H/W ROM Cost 

$16. 3M 

$22. 5M 

$1 2.8M 

Labor ROM 

$17. 0M 

$1 8.7M 

$1 7.0M 

Core S/W ROM 

0 

0 

$5.7M 

TOTAL ROM 

$33. 3M 

$41.2 

$35.5 


+ DMS Cost 

+ DMS Cost 

+ 0 


Life Cycle Cost 

Life cycle costs will be based on several factors including: 1) necessity and 
ease of hardware and software upgrades; 2) necessity and ease of hardware and 
software maintenance; 3) system reliability affecting training (production) time; and 4) 
ease of operation. Most of these factors are considered separately elsewhere. Aside 
from the quantity of components to be maintained, most life cycle cost factors are 
constant across the SCS designs. The exception is hardware related costs stemming 
from the different types of hosts and LANs comprising the designs. 

In designs where DMS kits are used, higher life cycle costs are expected for 
hardware maintenance. The specialized equipment configuration in the DMS Kits is 
expected to limit the maintenance resource options and thereby keep maintenance 
costs high. Considering the single source for the kits, upgrade and replacement costs 
are also expected to be high. Use of standardized, commercial hardware in the DMS 
Equivalent design should minimize these costs. However, as discussed previously, 
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any modifications or upgrades to SSF DMS elements will necessitate corresponding 
changes in the custom DMS software of the DMS Equivalent design keeping the life 
cycle costs high. In contrast, it is assumed such updates would be provided 
automatically by the SSF program to facilities using DMS Kits. 

Schedule Risk 

The likelihood of an SCS implementation encountering delays that could 
jeopardize training schedules or otherwise increase development costs is difficult to 
project. All three designs have degrees of risk associated with software development 
overruns, availability of hardware, and design/integration problems preventing 
criterion system performance. 

One apparent source of risk is the Local Host and Shared Host reliance on 
DMS Kits. Given a single supplier for these custom units, problems could arise in 
delivery of units, spares, diagnostics, and documentation. The design of the kits, and 
the SIB in particular, could also prove problematic in respect to efficient integration 
with other SCS components. The SIB's proprietary interface for connecting to a 
simulation host, for example, may represent an undue design constraint. 

Although these concerns do not arise with the DMS Equivalent design, initial 
development of the design's DMS simulation software carries the risk of a longer than 
expected development cycle. 

The Shared Host design also presents the risk that the 
multitasking/multiprocessing environment to manage simultaneous payload 
simulations across several lab trainers will prove difficult to implement. Such systems 
can experience drastic performance drops with small increases in the number of 
concurrent tasks. 

4.4 Computer Headroom 

All designs include base computing resources to sustain moderate increases in 
resource loading. (Assumptions made for the sizing analysis in Appendix I impose 
estimates of maximum load which will not practically occur). Appendix I and the sizing 
and loading tables show the basic analysis before the required 50% reserve factor is 
applied. This factor is attained easily by multiplying the Mips and network loading 
estimates provided by 1 .5. 

The provision of adequate computing headroom is least critical in the DMS 
Equivalent approach. This design has the advantage of small modular hosts that will, 
if any deficiency arises, simplify the incremental expansion of its computing power. 

The Shared Host design enjoys the intrinsic benefit of load balancing across a 
bank of hosts. This yields substantial functional headroom by allowing computing 
demands to be reapportioned dynamically for most SCS functions. Because 
individual payload operations are more likely to be sporadic than continuous in a 
training scenario, the steady state computing load level is expected to fall substantially 
below the potential peak levels. This characteristic favors the efficiency of a load 
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sharing architecture, especially when slight process delays due to extreme peaks are 
tolerable. 

4.5 Hardware/Software Compatibility and Standards 

There are two overlapping sets of hardware and software standards applicable 
to SCS designs. First are the SSF program standards pertaining to the 
implementation of flight articles and those pertaining to simulation systems. The 
second set of standards are those applicable industry/society standards relating to 
computer systems, communications, and software. By-and-large, the SSF standards 
are drawn from the second set of standards — the prevailing industry/society standards 
affecting commercial offerings at the national and international level. 

While an attempt is being made to adopt commercial standards within the SSF , 
the DMS Equivalent design offers more opportunities to configure SCS systems that 
exploit the compatibility and expandability benefits of standardized hardware and 
software. The selection of system elements and components in this design can be 
based more on a consideration of immediate market offerings and trends, than on SSF 
DMS design decisions. Outside of trainer implementations, however, the choices for 
implementing SCS facilities are the same for all SCS designs. 

4.6 Reconfiguration/Modularity 

As discussed previously, the DMS Equivalent design has the greatest degree of 
modularity and affords the most freedom for reconfiguring trainers. The Shared Host 
design, on-the-other-hand, offers the most latitude for rapid redistribution of computing 
resources. Also, as discussed in Section 3. 4. 2. 4, the Shared Host offers more options 
for interconnecting the individual lab and part task trainers. While not part of the 
PTC/SCS requirements, this capability affords useful flexibility in combining trainers 
into new configurations. Other aspects of reconfigurability are constant across the 
SCS designs. The Local host is most like many current systems, and has limited 
reconfiguration/modularity. New hosts would have to purchased for much of any type 
of growth or change. Since the hosts are dedicated to a particular trainer, if that host 
fails, no easy reconfiguration ability exists to recover. 

4.7 Ease of Operation 

The SCS designs all depend on the same Training Session Manager (TSM), 
network of Instructor Stations, and SCS support facilities (as well as operator 
consoles) to operate the trainers. Consequently, from a human machine interface 
perspective and a manning perspective, the SCS designs are comparable. 

4.8 Performance/Functionality Versus Cost 

All SCS designs satisfy functionality and performance requirements. Additional 
capabilities, where they exist, have been addressed. Overall, the designs vary in cost 
based on their inclusion of DMS Kits. Consequently, the DMS Equivalent approach 
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offers the best performance to cost ratio assuming the performance/functionality is the 
same for all three designs. 


4.9 Summary of Design Features. 


The table presented in Figure 4.9-1 summarizes the comparison of the three 
SCS desiqns The preceding paragraphs have addressed the more salient featur ^ 
and criteria for a successful SCS design. Meaningful comparisons among the 
conceptual designs have been related in the text to various tradeoffs among these 
factors P The tab?e indicates the relative position of the SCS designs in respect to each 

independent factor. 


FACTOR 

LOCAL 

HOST 

SHARED ! 

HOST 

DMS 

EQUIVALENT 

Reliability/ 

Maintainability 

Good 

Good 

Good 

Expandability/ 

Scalability 

Limited 

Good 

Good 

Cost 

High 

Lower 

Lowest 

Computing 

Headroom 

Limited 

V. Good 

Good 

H/W & S/W 
Standards 

Good 

Good 

Flexible 

Reconfigurability/ 

Modularity 

Limited 

Good 

V. Good 

Ease of 
Operation 

Good 

Good 

Good 

Performance 
vs Cost 

Fair 

Better 

Best 


Figure 4.9-1 Summary Results from a Comparison of SCS Designs 
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5.0 Conclusion 

The three SCS refined SCS conceptual designs each offers an effective 
solution for the PTC simulation system. Where warranted, these designs incorporate 
common design elements to insure that they completely and efficiently implement the 
SCS functions and features that have been underscored in this study as essential 
capabilities. Other potential SCS designs and hybrid combinations of the refined 
designs may satisfy PTC requirements equally well. In this case, the refined designs 
will provide the baseline architectures and performance necessary for a comparative 
analysis of final SCS designs. 

The ultimate design selection is principally contingent on SIB, DMS Kit, and 
SSE design decisions not yet made. The ultimate design selection is also contingent 
on schedule both the schedule for the DMS Kits, SIB, and SSE, and the timing of the 
actual SCS design process. The cost of various computers and the power of various 
COTS hardware and software will be large factors. The release of a new CPU of twice 
the power of previously available CPUs is occurring at an ever quickening pace. The 
amount of compute power, network capability, and other hardware costs are changing 
rapidly. 


Overall, the SCS Study has resulted in three viable refined design alternatives 
which can be used as the foundation for future SCS design work and analysis. Most 
importantly, the SCS Study has produced a thorough and well thought out set of SCS 
candidate designs satisfying detailed system requirements. 
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APPENDIX I. SYSTEM SIZING ANALYSIS 

The basic method and assumptions used to derive estimates of SCS design 
computing resource requirements are outlined in this appendix. Computing resources 
were estimated for the computational processing and communications necessary to 
support the basic SCS functions as delineated in the Function Allocation Matrices. 
The estimates are presented for purposes of sizing each SCS design in separate 
tables in the Detailed SCS Design Report. The LAN Loading tables (Figures 3.3. 1-3, 
3.4.1 -3, and 3.5. 1-3 in the report) tabulate the network loadings in the Local Host, 
Shared’ Host, and DMS Equivalent designs, respectively. The Host Loading tables 
(Figures 3.3.3-1, 3. 4. 3-1, and 3. 5. 3-1 in the report) tabulate the host loadings in these 
designs, respectively. 

Loadings on the SCS LAN and the trainer LANs are expressed as kilobits per 
second (Kbps) of input from the various hosts and processors. Process loadings on 
the hosts, themselves, are expressed as millions of instructions per second (Mips) for 
the SCS functions (application and operating system software). 

The LAN Loading tables reflect: 

- the communications requirements in Kbps placed on a design LAN by each SCS 
function (the predetermined Core and Payload LANS included in the DMS Kit are not 
considered). 

- distinction between real time and non-real time functions and requirements. 
(Because, when active, individual trainers are either engaged in a simulation training 
session (real time) or a setup period (non-real time), the maximum of the two loadings 
is used in the sum for the total estimate.) 

- the total LAN communications bandwidth requirement (Kbps) for each trainer and 
facility comprising the SCS design. (The maximum across lab trainer types is used as 
the "trainer LAN" total in the DMS Equivalent design.) 

- the total SCS LAN loadings based on the aggregate of the maximum estimates of 
communications requirements of all simultaneous SCS functions. 

The Host Loading tables reflect: 

- distribution of SCS functions across trainers and facilities. 

the total host computer cpu requirements in Mips for SCS functions (listed on left 
side of chart). 

- total host computer cpu requirements for each each trainer and facility. 

- total SCS design host computer cpu requirement. 
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1.0 PTC Configuration and Use Assumptions 

In order to determine rough order of magnitude (ROM) estimates for the SCS, 
several assumptions about PTC usage and configuration were made. These 
assumptions are based on analyses performed during the study, and documented in 
the Study Analysis Report, and a wide range of SSF information gathered over the 
course of the study. The report reflects the known SSF and PTC expectations held by 
NASA during this analysis phase. 

1.1 User Load on Physical Facility 

Number of people simultaneously trained in Consolidated Increment Trainer: 

Number of people simultaneously trained in each of the three Combined Trainers: 

4 

Number of people simultaneously trained in each of the nine Part Task Trainers: 2 

Number of people simultaneously trained in the Attached Payload Trainer. 1 

Number of people simultaneously trained in each of the seven POIC Trainers: 2 

Number of people simultaneously trained in the CBT Trainers: £ 

Number of people simultaneously trained in the entire PTC: 4Q Note. This sum 
does not equal the sum of all the Trainers since there would never be 100% 
utilization of all Trainers. 

Number of instructors in the PTC: 1_£ 

Number of simulation developers: 1QQ 

Number of integration and test personnel: 1_Q 

(could also be the proportion, at any one time, of development personnel 
engaged in IT&V tasks) 

Number of support personnel: 15 

Total number of people who work or train in the PTC at one time: 1_£Q 

1 .2 Number of Payloads per Trainer 

Total number of experiments in the Consolidated Increment Trainer: J2. (US 
Lab 36 + Columbus Lab 16 + JEM Lab 16) 

No. of simultaneous experiments in the Consolidated Trainer: 4£ 

It should be noted that while there will likely be more experiments in concurrent 
operation on the Space Station than this number, there will not be more than four crew 
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members on duty at any time. The other operating experiments do not require 
simultaneous operator intervention. In addition, while the other experiments do 
represent a load on Space Station resources, it is not necessary to model that load at 
a high fidelity in the PTC. (The load of the other experiments will be represented at a 
low fidelity). It should also be noted that the total number of experiments and the 
number of simultaneous experiments includes an appropriate proportion of attached 
payloads. 

Total number of experiments in the Combined Trainers: US Lab 36, Columbus 

Lab 16, JEM Lab 16 

No. of simultaneous experiments per lab: 24 USA 

12 Columbus 
12 JEM 


Total number of experiments in each Part Task Trainer: 4 

No. of simultaneous experiments in Part Task Trainer: 4 

Total number of experiments in Attached Payload Trainer: 4 

No. of simultaneous experiments in Attached Payload Trainer: 2 

Number of concurrent tests in IT&V : £ 

Number of experiments per processor (SDP, MDM): 1 

Percentage of experiments trained on with flight equivalent hardware: 1 0% 

Payload software models will be developed and used for training for 90% of the 
experiments. 


2.0 General Assumptions about SCS Functions 

The estimates included in this section are based, in part, on study analysis task 
T-l, Scope of Payload Crew Training in PTC, Report Volume 6. Where appropriate, 
the host computer loading results reflect the overhead Mips required by a 
multitasking/multiprocessing operating system. 

LAN loading values were derived from estimates of the maximum average 
message/packet lengths and their frequencies. The message/data traffic is divided 
into real time and non-real time functions. Given that real time and non-real time 
functions occur at separate times in the PTC, the larger of the two estimates was 
selected as the bandwidth requirement. 

The Mips shown in the Host loading tables reflect the estimated CPU power 
required to accomplish the associated SCS function. The US Combined Trainer was 
used as the based for all calculations. 
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Processing requirements for the SCS trainer and support facility functions have 
been estimated, in part, by comparison to known requirements for similar functions in 
real time and support systems previously developed and deployed by Grumman. 
Comparable real time systems include flight simulators, ship handling simulators, test 
stands, and command and control systems. Support systems include system and 
application programming environments for these real time facilities and for large MIS 
installations. Where possible, comparable program size in terms of lines of code and 
rate of repetition is used as the estimator. Otherwise, the size of the computing 
resources dedicated to the similar function is used as the estimator. Interpolation was 
used to scale the estimates when necessary. 

2.1 DMS Representation 

2.1.1 Assumptions 

We assume the estimates included in study analysis task T-1, Scope of Payload 
Crew Training in PTC, Report Volume 6, reasonably portray the code sizes of payload 
models. These estimates are higher level language code such as Ada. For 
conversion to host loading Mips, one line of Ada code is assumed to generate 
approximately 10 cpu instructions. 

For purposes of the sizing analysis, it was assumed that SCS simulation 
functions do not cycle at greater than 10 times per second, and that some functions 
such as payload operations may cycle less frequently (e.g., two times per second). 
Correspondingly, iterative software modules were assumed to repeat 10 times per 
second, or less as noted. These rates afford a background temporal resolution of 10 
hertz which is believed, for training objective purposes, to yield more than adequate 
fidelity. 

2.1.2 Processing Requirement 

DMS representations are accomplished in two ways: 1) by DMS Kits; and 2) by 
custom software on trainer hosts and other hardware. The DMS Kit components and 
their processing capacities are fixed by the SSF program and can not be treated as 
SCS design variables. Since the Local Host and Shared Host designs employ DMS 
Kits, these trainer computing resources are predetermined and are not included the 
the sizing analysis. However, where non-DMS solutions are used, such as NON-DMS 
Part Task trainers and the DMS Equivalent SCS design, the host processing loads are 
represented. 

The estimates included in the analysis are based, in part, on study analysis task 
T-1, Scope of Payload Crew Training in PTC, Report Volume 6. Where appropriate, 
the host computer loading reflects the additional cpu processing required to support a 
multitasking/multiprocessing operating system. 

The T1 study estimates that DMS software processing for Core systems 
functions, OMA, and DMS standard services requires 48,200 lines of code. This code, 
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assumed to execute at 4 hertz, was projected to require an additional 55 percent 
overhead for the operating system. 

The portion of this estimate attributable to software model representation of 
OMA and DMS services was taken to be 25 percent, with the remaining 75 percent for 
Core systems representation. Thus, 25 percent of 48,200, or 12,050, lines of code was 
used to estimate the DMS and OMA function requirements. In contrast to the i-i 
Study the code was assumed to execute at the full background frequency of 10 hertz 
to insure a capability for high system fidelity. Further, the overhead for the operating 
system was assumed to make up only 20 percent of the total processing load. 

Based on the above, the processing requirement for DMS representation is 
equivalent to: 

12,000 lines of code for DMS and OMA functions 
X 10 instructions per line of code 
X 10 hertz (cycle rate) 

X 1 .25 overhead (20 percent of total) 


1.5 Mips 

This estimate of host loading applies to all trainers where DMS representations 
are modeled with custom software and hardware. 

2.1.3 Communications Requirement 

Communications requirements impacting the LAN loading stem from the TGU 
data stream is implemented without the dedicated DMS timing bus (TDB). The 
maximum LAN loading is estimated on a maximum timing message size of 60 bytes 
being broadcast once every 100 msec: 

60 byte message 
X 8 bits per byte 
X 10 hertz resolution 


4.8 Kbps of bandwidth = approx. 5 Kbps. 

2.2 Core Systems Representation 

2.2.1 Assumptions 

Even though DMS designs may employ some flight equivalent Core software, 
substantial Core systems modeling will still be necessary. 

2.2.2 Processing Requirement 

Of the 48,200 lines of code estimated in the T-1 study, 75 percent is taken to 
represent Core system models. This is equivalent to approximately 36,150 lines of 
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code. The required processing resource to preserve a temporal resolution of 10 hertz 
is, thus: 

36,150 lines of code for Core models 
X 10 instructions per line 
X 10 hertz 

X 1 .25 overhead (20% of total) 


4.52 Mips = approx. 5 Mips 

In the Consolidated trainer, 1 Mips was added to support the additional 
requirements of the JEM Lab and Columbus Lab. 

2.2.3 Communications Requirement 

The LAN loading that results from Core system representations was estimated 
to take the form of a broadcast message with an average length of 50 bytes trar^mitted 
at a frequency 10 hertz. This translates to 4 Kbps of bandwidth loading on the SCS (or 
Payload) LAN. 

In the DMS Equivalent design, the bandwidth estimate was increased by a 
factor of 8 (to 32 Kbps) to accommodate message lengths up to 400 bytes that may be 
necessary for the total substitution of DMS components. 

Both estimates are based on comparisons to similar real time simulation 
functions associated with flight and ship handling training simulators. 

2.3 C & T Systems Representation 
2.3.1 Assumptions 

The aggregate science data downlink telemetry stream of all experiments is 
comprised of payload data borne by the Payload LAN and by the High Rate Link. 
When the aggregate stream must reflect a high bandwidth, it is typically modeled using 
a static, preformed data stream to augment the small dynamic data stream taken from 
the Payload (or Trainer) LAN. This latter stream may also include all uplink payload 
commands and downlink Core systems data and health and status responses 
generated by the models and flight equivalent instruments. It is assumed that, overall, 
High Rate Link data is generated by only five percent of the payload representations. 

When a dynamic, full bandwidth downlink telemetry stream is required in order 
to feed the POIC and/or the POIC Trainers, a separate, dedicated C&T processor 
platform will be used in conjunction with an SCS lab trainer. It is assumed, however, 
that only one trainer interacts dynamically with the POIC or the POIC Trainers at the 
same time. 

The Space Station science data component of the telemetry downlink is greater 
than 100 Mbps but will not typically be more than 150 Mbps. The PTC will not 
implement, simultaneously, more than one dynamic data stream of this magnitude. 
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2.3.2 Processing Requirement 

The C&T function is implemented at two levels , producing: 1) a limited 
bandwidth dynamic telemetry stream (but with a preformed full bandwidth static 
stream); or 2) a full bandwidth dynamic telemetry stream suitable for driving the POIC 
or its equivalent. 

Basic Model 

The basic trainer C&T representation is a software model capable of: 1) 
simulating the general telemetry environment and communication system control; and 
2) emulating, at a greatly reduced capacity, the fundamental C&T telemetry function of 
packet assembly and disassembly (PAD). 

While the code required to perform conversion and PAD-like functions can be 
complex, only a small portion of the code is used in a repetitive fashion to sustain a 
transmission. This subset of code was taken as the basis for estimating the throughput 
processing requirement. To provide a moderate capacity real time dynamic link, a 
1,000 hertz cycle frequency was used. 

80 lines of repetitive code 

X 10 instructions per line 

X 1000 hertz 

X 1.25 overhead 


1 MIP required for 10 Mbps C&T processing 

The PAD requirement of 1 Mip provides for a real time, dynamic C&T link of 10 

Mbps. 


The processing load for the communications control function was estimated on 
the basis of comparable existing code. The anticipated program size of 800 lines of 
repetitive code was used in the calculation. 

800 lines of repetitive code. 

X 10 instructions per line 
X 10 hertz 

X 1 .25 overhead (20% of total) 


1 Mips 

The resulting total basic C&T model requirement is estimated to be: 
1 Mips (PAD) + 1 Mips (control) = 2 Mips. 


Dedicated C&T Processor 
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The C&T processor/adapter performs the necessary communication processing 
to output a high fidelity telemetry data stream with a high bandwidth of greater than 
100 Mbps. Multiple processors can be combined to achieve even higher aggregate 
bandwidth telemetry data streams. 

The computing resource estimate of the required cpu processing Mips is based on a 
program containing a small module for the bulk of the sustained PAD-like 
communications processing: 

80 lines of repetitive code 
X 10 instructions per line 
X 10,000 hertz 
X 1 .25 overhead 


10 Mips 

2.3.3 Communications Requirement 

C&T processing imposes no additional load on the existing LAN traffic in any of 
the SCS designs. Generation of High Rate Link data when the flight equivalent 
payload instrument is not used, however, does yield an additional load as described in 
Section 2.18.3 Audio and Video System. 

2.4 Payload Representation 

2.4.1 Assumptions 

Payload sizing was based on the results of the T-1 Study which are assumed to 
reflect reasonable maximum payload models sizes. 

The control of several concurrent payloads presents a significant load on the 
operating system. This extra processing requirement for real time concurrency control 
is reflected in the estimates provided for the Simulation Executive function. 

2.4.2 Processing Requirement 

The temporal resolution (cycle time) required for payload models varies widely 
depending on the nature of the payload experiment and the fidelity of the payload 
model necessary to meet training objectives. The maximum fidelity or resolution that 
can be supported, without loss of precision, is equal to the background (DMS, Core, 
and C&T) processing rate of 10 hertz. The minimum resolution suitable for a payload 
model could be as low as several seconds or minutes per iteration (cycle). 

An average, high fidelity resolution of 2 hertz was used to determine the 
processing requirements. 

Size of Payload Models - T-1 Study 
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The payloads have been classified as complex, medium, and simple. The lines 
of code required for each type were estimated for: 

a complex model as 34,700 lines of code, 
a medium model as 22,000 lines of code, 
a simple model as 7,150 lines of code. 

In the extended analysis for detailed SCS design, the distributions of the 
experiment models was biased toward the complex side in order to insure maximum 
capacity. The mix of model types was assumed to be: 

Complex - 30% Medium - 30% Simple - 40% 

Based on this mix, the average module of code executed repetitively is 
estimated at 20,000 lines of code. 

The cpu processing requirement for the payload model of this size is: 

20,000 lines of code 
x 10 instructions per line 

x 2 hertz update rate 

x 1 .25 overhead (20% of total) 


5 Mips per payload model 
2.4.3 Communications Requirement 

The communications requirements for payloads vary based on the experiment's 
data acquisition and control profiles. The impact considered in this section is limited to 
the science and the health and status output which places a load on the Trainer or 
SCS LAN Many of these data streams may be lower than 1 Kbps on the average. 
The base rate used in this analysis for active payloads was .5 Mbps which, when 
summed for the number of simultaneous payloads, represents the instantaneous 
maximum to be expected for a lab trainer. 

For example, 12 simultaneous experiments in a Combined trainer times .5 
Mbps equals a total maximum load on the Shared Host SCS LAN of 6 Mbps. 

When payload science data is selected and routed for monitoring, such as 
during instructor monitoring in the Local Host design, the data stream from each 
selected payload is assumed not to exceed 2 Mbps. The corresponding impact on 
LAN loading is described in Section 2.11.3 Instructor Control and Monitoring. 

2.5 Environment Representation 

2.5.1 Assumptions 

Environment models are necessary to sustain DMS, payload, and Core system 
functions, and to structure training session simulation scenarios. 
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The implemented fidelity of environment models varies with the type of SCS 
trainer. 

2.5.2 Processing Requirement 

It is estimated that full environment models providing adequate fidelity for the 
the Combined and Consolidated trainers will account for 24,000 lines of code. Since 
environment models are part of the matrix driving payload instruments and models, 
they must be able to execute at the background frequency of 10 hertz. 

The resulting maximum cpu processing requirement is: 

24,000 lines of code 
x 10 instructions per line 
x 10 hertz 
X 1.25 overhead 


3 Mips 

2.5.3 Communications Requirement 

The communications requirement associated with the environment models was 
estimated on the basis of a single LAN broadcast message at the maximum 
background rate of 10 hertz. These messages could represent space, space station, 
and ground environment variables and related systems data. The average message 
was assumed to contain 100 four byte variables. 

The resulting load on the SCS or Trainer LAN is: 

100 environmental variables 
X 4 bytes long 
X 8 bits per byte 
X 10 hertz 


32 Kbps 

2.6 Crew Interface Representation 
2.6.1 Assumptions 

MPAC usage is distributed accordingly: 

Consolidated Increment Trainer: 2 USA, 1 JEM, 1 Columbus 
Combined Trainer: 2 USA , 2 JEM , 2 Columbus 
Part Task Trainers: 1 

Audio and video I/O is not considered in this analysis because these data 
streams are isolated from SCS design LANs. The streams are both internal to the 
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console and sourced from a separate Audio and Video System over dedicated 
communications links which are independent of the SCS and Trainer LANS. 

Experiment displays available on the flight MPAC are simulated with high 
fidelity. 

The switches and indicators on the Control and Display Panel may be 
simulated at a medium fidelity. 

2.6.2 Processing Requirement 

It is assumed that a windowing environment and local array processing will be 
required of the crew console to provide realistic interactive graphics. In conjunction 
with requirements for peripheral I/O including video, it is estimated that the function 
requires a workstation with a minimum of 5 Mips cpu power. 

2.6.3 Communications Requirement 

LAN loading estimates for the MPAC and its non-DMS equivalent are based on 
a maximum expected command stream output represented by the interaction of a 
position controller such as a joy stick. A data rate of 50 Kbps was used. 

2.7 Simulation Executives 

2.7.1 Assumptions 

The Simulation Executive is responsible for essentially all real time simulation 
control and coordination within a trainer. This includes the orchestration of payload 
models, DMS, Core systems, SIB, instructor interfaces, performance recording, and 
interfaces with network control programs during a training session. 

Each trainer has its own Simulation Executive. 

2.7.2 Processing Requirement 

The Simulation Executive's real time function is required to interact with the 
trainer systems at the background frequency of 10 hertz. The scope of the executive 
requires substantial software support. Based on similarity to other complex real time 
systems, the total program size is estimated to be approximately 20,000 lines of code. 
It is estimated that the repetitive code module necessary to support a single function, 
such as an active payload model or a monitoring/recording activity, is approximately 
1,000 lines of code. 

On the average, it can be expected that approximately 20 active payloads and 
other simulation functions can occur simultaneously in a full fidelity lab trainer. In 
order to span these concurrent events, the equivalent of one repetitive code module 
must be executed for each function. 



TRW-SCS-89-T5 Refined 1 Design 9 4 


Therefore, the re petiti ve , time sharing nature of a Simulation Executive is 
expected to require: 

20 concurrent functions 
X 1 ,000 lines of code 

X 10 instructions per line 

X 10 hertz 

X 1 .50 overhead (40% of the total) 


3 Mips 

The operating system overhead appears higher in these estimates because of 
the high sustained level of concurrency necessary to execute the simulation. The 
Simulation Executive code is also responsible for the interface and synchronization of 
models with the trainer and SCS system components. Much of this processing 
invokes operating system resources. 

2.7.3 Communication Requirement 

The communications requirement necessary to control payload operations has 
been estimated to range from 1 to 1.5 Kbps per payload model. This bandwidth 
provides for ten 12 byte command messages per second per payload. 

2.8 POIC - DMS Interface 

2.8.1 Assumptions 

The POIC-DMS interface can be represented by both a real time interface to the 
POIC (or a POIC Trainer) and a ground control model running in the trainer host. 

The POIC-DMS Interface is assumed to interact with the OMA or equivalent 
models on a real time basis. Uplink commands and responses are modeled fully. 

A trainer's modeled telemetry stream includes Core systems data, Payload LAN 
data, High Rate Link science data, and audio communications. These data are, in 
turn, reacted to by the modeled POIC ground systems. 


2.8.2 Processing Requirement 

The size of the POIC-DMS interface model was estimated at 8,000 lines of 
code. This translates to 1 Mips of cpu processing power. 
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The 1 Mip computes as follows: 

8,000 lines of code 
x 10 instructions per line 
x 10 hertz 
x 1 .25 overhead 


1 Mips 

An additional 1 Mips was added to the Consolidated trainer to support the 
requirements of the JEM Lab and Columbus Lab. 

2.8.3 Communications Requirement 

The communication requirements for the POIC - DMS interface are based on a 
maximum expected command stream output represented by the interaction of a 
position controller such as a joy stick. A data rate of 50 Kbps was used. 

2.9 PTC -POIC Link 

2.9.1 Assumptions 

It is possible, with the aid of the C&T processor box, to connect the PTC directly 
to the POIC or a physical representation of it. In these cases, it is assumed that only 
one trainer interacts dynamically with the POIC or POIC Trainer. 

The Space Station Science data components of the telemetry stream downlink 
is greater than 100 Mbps but will not be typically more than 150 Mbps. The PTC will 
not implement at any given time more than one dynamic data stream of this 
magnitude. 

2.9.2 Processing Requirement 

The processing requirements associated with PTC-POIC link parallel that of the 
C&T communications processor. The processor, under the control of the Training 
Session Manager host and coupled with a high speed LAN or telecommunications 
link, provides the computing resource for this function. 

C&T Dedicated Processor 

This processor and adapter supports a C&T telemetry link of greater than 100 
Mbps. Multiple processors can be used to achieve still higher aggregate capacity 
communications link. 

The cpu processing power required is estimated on the basis of a small, rapidly 
cycling module of code serving as the core of this function. Consequently: 
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80 Lines of repetitive code 
X 10 instructions per line 
X 10,000 hertz 
X 1 .25 overhead 


10 Mips 

2.9.3 Communications Requirements 

The PTC - POIC represent no communications load on the SCS LAN. 

2.10 GSE Control 

2.10.1 Assumptions 

Ground Support Equipment (GSE) is a simple model which supplies control 
signals to GSE control devices or payload stimulators, or simulates ground support 
equipment functions in order to furnish parameter values to payload models. 

Ground Support Equipment is external to the SCS within the PTC. 

2.10.2 Processing Requirement 

The necessary GSE fidelity in terms of temporal resolution will vary with the 
nature of the payloads and the models implemented to meet training objectives. The 
resulting cpu processing requirement is expected to be quite modest. Based on a total 
repetitive code of 4,000 lines executing at an average cycle rate of 2 hertz, the 
estimated requirement is: 

4000 lines of code 
X 10 instructions per line 
X 2 hertz 
X 1.25 overhead 


.1 Mips 

2.10.3 Communications Requirement 

The communications requirement per payload is based on the amount and 
frequency of control data used to drive the GSE device or the payload stimulator. 

The estimated 0.5 Kbps is derived from an expected 30 bytes of command data 
per payload recurring at 2 hertz. 

2.11 Instructor Control and Monitoring 

2.11.1 Assumptions 

Instructor Stations are located on the SCS LAN. 
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Trainer audio and video are feed to and from the Instructor Stations via the 
separate Audio and Video System. 

An Instructor Station may be used to monitor more than one (and up to four) 
trainers, crew consoles, or separate payloads at the same time. 

2.11.2 Processing Requirement 

In each of the SCS designs, the instructor stations were implemented as 
individual workstations. The workstation needs to be capable of supporting the 
operating system and file transfers, the windowing environment, multiple active 
processes in separate windows, local administrative processing, and control of audio 
and video equipment. It was determined, from known performance with similar 
tasking, that a high end workstation of approximately 16 Mips is required. 

2.11.3 Communications Requirements 

The Instructor Station consoles are assumed to be a source of command 
streams into the trainers equivalent to the output of a position controller, or a 
parameter array for dynamic adjustment of simulation scenario events. A data rate of 
50 Kbps was used. 

Data traffic from the trainers to the consoles for monitoring functions differs 
among SCS designs. It has been assumed elsewhere that the maximum average 
data output of a payload onto the Payload LAN (not High Rate Link data) is 1.5 Mbps. 
To insure adequate monitoring capacity for payloads above this average, a 2 Mbps 
stream is assumed in this analysis. Further, this 2 Mbps may be the filtered result of an 
even larger payload data stream, when necessary. 

In the Shared Host design, the full data stream is already on the SCS LAN 
when the payload source is a model (running on a shared host). 

If, on-the-other-hand, the data originates from a flight equivalent instrument, the 
full payload data stream is routed through the SIB onto the SCS LAN. This presents 
an additional loading on the SCS LAN as shown in Figure 3.4. 1-3. It is assumed that 
in these cases, the PTC/SCS-wide maximum number of payloads being viewed 
concurrently by instructors is 10 and that the data streams are filtered down to 2 Mbps, 
if necessary. 

The presence of the trainer host(s) in the Local Host and DMS Equivalent 
designs, permits the payload data stream to be filtered to provide just what data can be 
displayed as a whole on an Instructor Station console. The resulting data stream used 
is 300 Kbps per concurrently viewed payload. 

It should be noted that these loadings do not reflect audio and video signals 
which, in all SCS designs are routed directly to the consoles by a separate Audio and 
Video System which does not use the SCS or other LANs. 
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2.12 Training Session Manager 

2.12.1 Assumptions 

Trainer hosts have local disk which support virtual memory swapping, operating 
system requirements, training scripts, code management, and all required data bases. 

In two of the three design, the TSM receives training results from the transfer in 
a non-real time mode. The exception is the Shared Host design where training result 
are transferred in real time. 

The Training Session Manager coordinates and controls instructor interactions 
with the Simulation Executives. 

The training Session Manager controls all external communications with the 

PTC. 

Training analysis and data base functions reside on the Training Session 
Manager Host. 

2.12.2 Processing Requirements 

The TSM's function is comprised predominantly of non-real time tasks 
associated with the configuration and setup of the trainers and interfacing with the 
management of training data. (Actual training data analysis and management tasks 
are covered later as separate functions). The computing resource host loading for the 
TSM is estimated to be 3 Mips as indicated, for example, in Figures 3. 3. 3-1 and 3.5.3- 
1. The estimate is based on engineering judgement for an acceptable response time 
for complex tasks across several independent trainers and facilities. 

2.12.3 Communications Requirements 

The Training Session Manager produces some loading on the SCS LAN during 
both real time and non-real time operations. During real time operation, the TSM 
interacts with Instructor Stations to set up basic transaction sessions between the 
instructors and one or more Simulation Executives. The TSM also monitors the basic 
status of each Simulation Executive/Trainer. 

The LAN loading estimated at .14 Kbps per instructor station represents the 
passage of infrequent commands to the Simulation Executives and includes status 
data flowing the other direction. 

The maximum non-real time loading on the LAN during configuration and setup, 
assuming all trainers are prepared at the same time, is summarized in Figure 1-1. 
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3 

2.22 

Totals 
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Figure 1-1. Configuration and Setup Analysis 

1. Goal was to configure the PTC in under 10 minutes. 

2. The Development Facility and TSM will load SCS LAN. 

3. Trainer response to transfer is minimal. 

4. Sizes of application from T-1 Study. 


2.13 Operator Control and Monitoring 

Operator Control and Monitoring functions are performed on system consoles 
that reside on the various SCS hosts. Operator functions consist primarily of non-real 
time functions and no not require additional processing power, or contribute to the 
network loading. 

2.14 Configuration and Setup 

The bulk of the processing associated with this function is performed as part of 
the TSM function and has already been included in those estimates. 

2.15 Training Analysis 

2.15.1 Assumptions 

Training Analysis is supervised by the Training Session Manager in a non-real 
time mode. 

2.15.2 Processing Requirements 

In addition to Training Session Manager supervision, host support of training 
analysis includes processing for descriptive statistics, multivariant inferential statistics, 
and plots and graphs. These tasks can be implemented with COTS software 
packages. Custom software would support (but not concurrently) the analysis of 
scenario session recordings to abstract meaningful data for submission to the statistics 
packages. The cpu processing load estimated to perform these functions within a 
reasonable time frame is 4 Mips for application code and database operation. 
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2.15.3 Communications Requirements 

There is no communications requirement beyond the transfer of training data 
achieved in the Training Data Management function, described in the next section, that 
would impact the SCS LAN loading. 

2.16 Training Information Management 

2.16.1 Assumptions 

Training data are collected in real time via the Simulation Executives and 
transferred to the Training Session Manager for record keeping and administration. 
These data are also submitted to, and the results received from, the Training Analysis 
function described above. 

2.16.2 Processing Requirements 

In addition to Training Session Manager supervision, host support of training 
information management includes all data base functions and report generation. 
These tasks would be implemented with COTS software packages. Custom software 
would support (but not concurrently) the capture and storage of scenario session 
recordings. The cpu processing load estimated to perform these functions within a 
reasonable time frame is 4 Mips for application code and database operation. 

2.16.3 Communications Requirements 

SCS LAN loading is based on the following estimates: 

3.000 records of 80 bytes per student in Consolidated and Combined trainers. 

1 .000 record of 80 bytes per student in the Part Task trainers and CBT trainers. 

Average of two minutes allowed to transfer data from trainers. 

When multiplied by the number of trainers and students, a total of 47,360 Kbits 
needs to be transferred. A composite transfer rate of 550 Kbps enables the data to be 
transferred from all trainers in approximately 2 minutes. The calculations are 
summarized in Figure 1-2. 
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Figure 1-2. Training Results Transfer Analysis 
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Goal was to keep transfer time for training results under two minutes. 


2.17 POIC Personnel l/F 

The PTC includes seven POIC trainers. Each trainer supports a host and two 
workstations. The host processes and controls all uplink and downlink exchanges 
and provides disk storage capacity to the workstations. 

Each of the seven POIC trainers includes a host and two workstations. The 
workstations support a windows environments and connections to the Audio and 
Video System. 

The processing requirements estimated for a POIC Trainer are. 

POIC host . 8 Mips 

Workstation... 4 Mips *2 = 8 Mips 


16 Mips 


The host requirements stem from: 

C&T processing 5 Mips 

File Server, OS, Sim Exec 3 Mips 

4 MIPS is a small workstation capable of supporting graphics, windows, and 
operating systems. 


2.18 PTC External Interfaces 


The joint combined training mode with JSC is not specified. For this reason, 
there is no requirement for real time data interchange between the SSTF and the P lu. 
File transfers between the SSTF and the PTC are supported. File transfers between 
the PTC and the Pis are supported. 


2.19 Audio and Video Systems Representation 

An Audio/Video Processor/Controller is used to augment the Trainer Host. 

Five percent of all payload models require AA / generation. 

Additional communications processing is required to support High Rate Link 
data creation when the flight equivalent instrument is not used. The High Rate Link 
function of the corresponding payload model generates the command that 

drives the actual source device (of telemetry data stream), such as the Audio and 
Video System. This specialized device then generates the actual High R^e Link data 
stream for feed to the facility's dedicated C&T processor, and on to the POIC or POlO 
Trainer link. 
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The additional processing requirement was estimated as the maximum for a 
single payload model, recalling that only five percent of the payloads are expected to 
qenerate High Rate Link data. Basing the maximum estimate on a computer 
generated imagery requirement of one command statement (18 bytes) for every 
Kilobyte of video data, and a maximum High Rate Link output for a single payload of 
40 Mbps, results in: 

18 bytes (command) 

X 8 bits per byte 
X 5,000 kilobyte units of video data 
(for an 80 Mbps stream) 


0.72 Mbps = approx. 0.75 Mbps LAN loading 

In the example of one full fidelity Combined lab trainer with two simultaneously 
active HRL payloads, the total LAN loading for that trainer is 1 .5 Mbps. 

2.20 Primary Instruction Delivery 

The SCS facilities, including the CBT Facility, were designed, configured, and 
sized on the basis of general system architecture and engineering experience with 
similar general purpose MIS and development implementations. The basic allocation 
of cpu processing and communications resources to accommodate reasonab e 
expectations for the specific functional loadings on the facility are provided in the 
following sections. 

2.20.1 Assumptions 

CBT models are of low fidelity. 

CBT models may require prerecorded audio and video inputs. 

Eight students will be training at one time. 

2.20.2 Processing Requirement 

The CBT is configured with host file server and eight disk or diskless 
workstations. The CBT file server provides data base and file services to the 
workstations as well as handle any SCS LAN request. Training results are kept on 
CBT file server and transferred to the training session manager in a non-real time 

mode. 


Based on engineering experience with comparable configurations, the 
processing load on the CBT file server is estimated to be not more than 8 Mips. 

The processing load on the workstations, with or without local disk storage, is 
estimated to be 4 Mips. 


TRW-SCS-89-T5 


Refined Design 1 03 


2.21 Simulation, Scenario, and DB Development 


The SCS facilities, including the SCS Development Facility, were designed, 
configured, and sized on the basis of general system architecture and engineering 
experience with similar general purpose MIS and development implementations. The 
basic allocation of cpu processing and communications resources to accommodate 
reasonable expectations for the specific functional loadings on the facility are provided 
in the following sections. 


2.21.1 Assumptions 

The facility must support 100 concurrent users in the development of payload 
models, training scenarios, and other simulation models and databases. 

A variety of workstations and graphics terminals can be used to support the 
development effort. 

2.21.2 Processing Requirements 

The SCS Development Facility has been configured to consist of 40 
workstations in total, of which 30 workstations are allocated to support the 
development of simulation models, scenarios, and database software Thus, the 
function relies on 30 workstations at 8 Mips per workstation for a total computing 
capacity of 240 Mips. 

In addition, 70 Mips of the dual file servers is allocated to support databases, 
compilers, debuggers, and multiple batch jobs. 

2.21.3 Communications Requirement 

The separate facility LAN supports virtually all communications requirements for 
the development function, and has been sized at 10 Mbps which is considered more 
than adequate to support file services under the given configuration and number of 
stations. Average response time for queries would be expected to be on the order of 1 
to 2 seconds. 


2.22 Developers Interface 

The Developer Interface function of the SCS is actually a subset of the SCS 
Development Facility described in the previous section. Additional requirements 
associated with this aspect of the facility are identified below. 

Sixty terminals connect to the host file servers via terminal servers. The 
terminals rely on the cpu processing capacity of the host file servers. The allocated 
host cpu processing requirement per terminal/user is 1 Mips, where: 

60 users * 1 Mips = 60 Mips allocation. 

Similarly, the file server load for a diskless workstation is 1 Mips, where: 
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20 Workstation * 1 Mips = 20 Mips. 

Twelve Mips are allocated for expansion and additional processing support to 
the higher capacity workstations. 

2.23 Crew Interface Prototyping 

The prototyping activity for crew interfaces including C&D panels and virtual 
C&D panels is a subset of the Development Facility function. Additional cpu 
processing allocated to support specific prototyping environments takes the form of six 
workstations. Five of these 6 Mips workstations are used as prototyping stations, with 
the sixth workstation used as a file server. 

2.24 Integrate and Test Simulations 

The SCS facilities, including the IT&V Facility, were designed, configured, and 
sized on the basis of general system architecture and engineering experience with 
similar general purpose MIS and development implementations. The basic allocation 
of cpu processing and communications resources to accommodate reasonable 
expectations for the specific functional loadings on the facility are provided in the 
following sections. 

2.24.1 Assumptions 

It is assumed that the larger, more complex payload models will require 
significantly more IT&V time, thus altering their proportion in the payload model mix 
used to set the average cpu loading. To accommodate this shift, the average 
requirement of a payload model was increased from .5 Mips to 1 Mips. 

It is assumed that 6 of the developers will be testing payloads concurrently. 

2.24.2 Processing Requirements 

Based on an estimate of an additional 3 Mips to support debugging and other 
capabilities unique to IT&V tasks, 18 Mips was allocated to the IT&V host to support the 
testing of 6 payloads concurrently. This processing capacity is in addition to that 
resident in the IT&V lab configuration unit which is equivalent to a Combined Trainer. 



